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(57) ABSTRACT 

A media manager provides data flow management and other 
services for client applications on devices coupled together 
within a network. Preferably, these devices are coupled 
together within an IEEE 1394-1995 serial bus network. A 
device control module is generated for each available device 
for providing an abstraction for all of the capabilities and 
requirements of the device including the appropriate control 
protocol, physical connections and connection capabilities 
for the device. The media manager also manages the flow 
and format of data transfers between the devices on the 
network. Through an interface, a user accesses the media 
manager and enters functions which are to be completed 
using the devices coupled together on the network. If the 
appropriate devices are available, the media manager con- 
trols and manages the completion of the requested task. If 
the appropriate devices arc not available, but the required 
subdevices are available in multiple devices, the media 
manager forms a virtual device from subdevices in multiple 
devices in order to complete the requested task. Once the 
appropriate devices and subdevices are assigned to a task, 
the media manager determines if the data to be transmitted 
needs to be converted from one format into another format. 
If necessary, the media manager will also control the format 
conversion during the data transfer operation. The media 
manager also provides network enumeration and registry 
searching capabilities for client applications to find available 
services, physical devices and virtual devices. 

43 Claims, 6 Drawing Sheets 
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MEDIA MANAGER FOR CONTROLLING possible that one or more such devices will be coupled 

AUTONOMOUS MEDIA DEVICES WITHIN A together in a network with a personal computer, settop box 

NETWORK ENVIRONMENT AND or other device including a microprocessor Currently, there 

MANAGING THE FLOW AND FORMAT OF is a lack of available interfaces and control applications 

DATA BETWEEN THE DEVICES s which will efficiently manage interaction and operation of 

the autonomous devices within such a network configura- 
This application is a continuation of U.S. patent appli- lion. What is needed is an interface which allows a control- 
cation Ser. No. 09/075,047 filed on May 8, 1998 now U.S. ling device within a network configuration to efficiently 
Pat. 6,233,611. control communications between the devices and the opera - 

10 tion of the devices within the network. What is further 
FIELD OF THE INVENTION needed is an interface which allows a controlling device 

„ , . i ♦ * 4 u « u * within a network configuration to maximize the availability 

The present invention relates to the field of managing . ... & , f , .. - , ' 

v 5 j j . .... . , . _ * of devices within a network for completion of tasks and 

applications and devices within a network environment. 

More particularly, the present invention relates to the field of p 

managing the operation of and the communication between SUMMARY OF THE INVENTION 

devices within a network environment. A media manager pr0 vides data flow management and 

BACKGROUND OF THE INVENTION otncr for cuent applications on devices coupled 

together within a network. Preferably, these devices are 

The IEEE 1394-1995 standard, "1394-1995 Standard For M coupled together within an IEEE 1394-1995 serial bus 
A High Performance Serial Bus," is an international stan- network. A device control module is generated for each 
dard for implementing an inexpensive high-speed serial bus available device for providing an abstraction for all of the 
architecture which supports both asynchronous and isoch- capabilities and requirements of the device including the 
ronous format data transfers. Isochronous data transfers are appropriate control protocol, physical connections and con- 
real-time transfers which take place such that the time ^ nection capabilities for the device. The media manager also 
intervals between significant instances have the same dura- manages the flow and format of data transfers between the 
tion at both the transmitting and receiving applications. Each devices on the network. Through an interface, a user 
packet of data transferred isochronously is transferred in its accesses the media manager and enters functions which are 
own time period. An example of an ideal application for the to be completed using the devices coupled together on the 
transfer of data isochronously would be from a video 30 network. If the appropriate devices are available, the media 
recorder to a television set. The video recorder records manager controls and manages the completion of the 
images and sounds and saves the data in discrete chunks or requested task. If the appropriate devices are not available, 
packets. The video recorder then transfers each packet, but the required subdevices are available in multiple 
representing the image and sound recorded over a limited devices, the media manager forms a virtual device from 
time period, during that time period, for display by the 35 subdevices in multiple devices in order to complete the 
television set. The IEEE 1394-1995 standard bus architec- requested task. Once the appropriate devices and subdevices 
ture provides multiple channels for isochronous data transfer are assigned to a task, the media manager determines if the 
between applications. A six bit channel number is broadcast data to be transmitted needs to be converted from one format 
with the data to ensure reception by the appropriate appli- into another format. If necessary, the media manager will 
cation. This allows multiple applications to simultaneously 40 also control the format conversion during the data transfer 
transmit isochronous data across the bus structure. Asyn- operation. The media manager also provides network enu- 
chronous transfers are traditional data transfer operations meration and registry searching capabilities for client appli- 
which take place as soon as possible and transfer an amount cations to find available services, physical devices and 
of data from a source to a destination. virtual devices. 

Hie IEEE 1394-1995 standard provides a high-speed 45 BRIEF DESCRIPTION OF THE DRAWINGS 
serial bus for interconnecting digital devices thereby pro- 
viding a universal I/O connection. The IEEE 1394-1995 FIG. 1 illustrates an IEEE 1394-1995 serial bus network 
standard defines a digital interface for the applications including a video camera, a video cassette recorder, a 
thereby eliminating the need for an application to convert computer, a television and settop box. 
digital data to analog data before it is transmitted across the 50 FIG. 2 illustrates a block diagram of a hardware system 
bus. Correspondingly, a receiving application will receive resident in each device implementing the media manager of 
digital data from the bus, not analog data, and will therefore the present invention. 

not be required to convert analog data to digital data. The FIG. 3 illustrates a block diagram of the architecture of 

cable required by the IEEE 1394-1995 standard is very thin the media manager platform of the present invention, 

in size compared to other bulkier cables used to connect such 55 FIG. 4 illustrates a detailed block diagram of the archi- 

devices. Devices can be added and removed from an IEEE tecture of the media manager platform of the present inven- 

1394-1995 bus while the bus is active. If a device is so uon< 

added or removed the bus will then automatically reconfig- pjQ 5 illustrates a flow diagram of the steps involved in 

ure itself for transmitting data between the then existing setting up and data transfer between two devices using the 

nodes. A node is considered a logical entity with a unique 60 me di a manager of the present invention. 

address on the bus structure. Each node provides an iden- FIG 6 ^5^5 a flow diagram followed by a client 

tification ROM, a standardized set of control registers and its application during startup. 

own address space. 

Mcdiadevicesarebeingcquippedwithnetworkinterfaces ^^S^SS^S^ 

allowing them to become part of a network such as the IEEE 65 FKbhbKKEU fcMtfUUiMbN 1 

1394-1995 serial bus network. In a home audio/video net- The media manager of the present invention provides data 

work incorporating such autonomous media devices it is flow management and other services for physical devices 
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within a network. A physical device is a product sold as a coupled to a user interface 30. The printed circuit board 20 
separate component by a vendor. Examples of physical includes a central processing unit (CPU) 22 coupled to 
devices include televisions, video cassette recorders, per- system memory 24 and to an I/O bus interface 26 by the 
sonal computers, video cameras, CD-Rom players and the system bus 28. The use of the term 'CPU' is not intended to 
like. Many other examples are also well known and com- 5 mpty mat sucn a system must be a general purpose com- 
mercially available. Each physical device includes a number P utin 8 circuit Rather > this circuit could be implemented with 
of subdevices. For example, a typical commercially avail- a S eneraJ V*rpo& controller or special purpose circuit. The 
able video camera includes multiple subdevices, implement- user 3 ° j f ^° c L 0U P led to the .! vste L m bus ™ e 
ing different functionalities, such as the camera and the user interface 30 is subsystem specific, but preferably 
video player 10 "^h^es at l east an infrared remote control device and a 
. . * i - ij. display. Alternatively, the user interface 30 also includes 
* eferab &y™£ dev "* s are coupled together * \ & for communicati with a user of the 
within an IEEE 1394-1995 serial bus network. A device , 6 
control module (DCM) is generated for each available T \, ' , , , c . . . 4 , 
device and subdevice. Each DCM provides an abstraction preferred embodiment of the present invention, the 
for an of the capabilities and requirements of each physical U media manager is included I w.thm a device such as a 

device, including the appropriate control protocol, physical tele ™ 01 a ^ dls ^> m order , to 

\. *f t . a^J^I -n, a smooth interaction with the user. However, it should be 

connections and connection capabilities for the device. The i . A . ,. _ L ' . 

media manager also manages the flow and format of data Warent tha the media manager of the present invent.on can 

transfer operations between the physical devices on the *° b / ™Pkmented on any other capable device which 

network, including converting the data into a different ™ * c,u , d « h thc component necessary o. -proving an inter- 

r * 1 • ±t- j i i c face to the user. In order to implement the media manager of 

format during the data transfer operation. . r . 

° r the present invention, each component in which it is lmple- 

Through an interface, a user accesses the media manager mented ^ a nardware system mch ^ the system 

and enters functions and tasks which are to be completed ii lustrat ed in FIG. 2. The CPU 22 within such a device is 

using the physical devices within the network. If the appro- used lQ execute me application program instructions. The 

priate physical devices are available and are not otherwise media manager of lhe preserjt invention is then used to 

being used, the media manager controls and manages the man ag e communications and operations within the network, 

completion of the requested task. If the appropriate physical ^ user accesses tne media man ager through the interface 

devices are not available, the media manager attempts to provided at foe controlling device. Through this interface the 

create a virtual device from available subdevices or com- user can monitor the operation and status of the network and 

ponents within devices in order to complete the requested thc deyiccs thc network . ^ can a lso contro i the 

task. Once the appropriate physical devices and/or subde- dev i ce s and request tasks to be completed through this 

vices are assigned to a task, the media manager determines interface. An example of these tasks include playing a 

if the data to be transmitted needs to be converted from the rec0 rded tape on the VCR 12 and displaying the output from 

format of the source device to the format of the receiving ^ ^ VCR 12 on ^ television 11. The media manager of the 

device. If a conversion is necessary, the media manager also VKSCni invention also manages data transfer operations and 

controls that operation while controlling the data transfer (agks rcquestcd at the individual devices, 

operation. ^ block diagram of the architecture of the media manager 

FIG. 1 illustrates an exemplary system including a video platform of the present invention is illustrated in FIG. 3. This 

camera 10, a video cassette recorder 12, a computer 14, a 4Q architecture is divided into a so-called upper portion 32 and 

settop box 13 and a television 11 connected together by the a lower portion 34. The lower portion 34 preferably includes 

IEEE 1394-1995 cables 15, 16 and 18. The IEEE the IEEE 1394-1995 bus interface and functionality support 

1394-1995 cable 16 couples the video camera 10 to the across the most common commercial operating systems 

video cassette recorder 12, allowing the video camera 10 to currently available. The upper portion 32 includes compo- 

send data to the video cassette recorder 12 for recording. The 45 neats wnicn bring together the underlying IEEE 1394-1995 

IEEE 1394-1995 cable 18 couples the video cassette bus suppQTi m ^ a dd in a number of features and enhance- 

recorder 12 to the computer 14, allowing the video cassette ments wn i c h are provided to the client applications and 

recorder 12 to send data to the computer 14 for display. The therefore to the user. Hie upper portion 32 includes the block 

IEEE 1394-1995 cable 15 couples the settop box 13 to the 4^ wn i cn provides specific design and implementation for 

computer 14. The settop box 13 is also coupled to the 5Q higher level IEEE 1394-1995 bus support, and the block 48, 

television 11 by the cable 17. which includes and provides interfaces to the various client 

This configuration illustrated in FIG. 1 is exemplary only. applications. The lower portion 34 includes the blocks 40, 42 

It should be apparent that an audio/video network could and 44 which provide support for the most common oper- 

include many different combinations of physical compo- ating systems, including Windows 95®), Macintosh® and 

nents. The physical devices within such an IEEE 1394-1995 55 Aperios™ operating systems, respectively. Support for any 

network are autonomous devices, meaning that in an IEEE general operating system, such as OS9, is also provided. The 

1394-1995 network, as the one illustrated in FIG. 1, in lower portion 34 also includes the block 38, which provides 

which a computer is one of the devices, there is not a true the common layer of IEEE 1394-1995 support, and the 

"master-slave" relationship between the computer and the blocks 36 which provide the actual physical IEEE 

other devices. In many IEEE 1394-4995 network 60 1394-1995 bus interfaces to other devices coupled to the 

configurations, a computer may not even be present. Even in controlling device. 

such configurations, the devices within the network are fully The media manager platform provides an open and flex- 
capable of interacting with each other on a peer basis. ible architecture in order to efficiently integrate personal 
A block diagram of a hardware system resident in the computers and other autonomous devices into a network 
managing device for implementing the media manager of 65 configuration and effectively manage the necessary data 
the present invention is illustrated in FIG. 2. In the hardware transfer operations between those devices. The lower por- 
system illustrated in FIG. 2, a printed circuit board 20 is tion 34 of the architecture has been designed to support the 
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underlying technology at the lowest levels, which allows the 
higher levels to support more general modules and func- 
tional descriptions. 

A more detailed block diagram of the architecture of the 
media manager platform of the present invention is illus- s 
trated in FIG. 4. The multimedia or user-level application 48 
sits at the top of the architecture and makes use of the 
services provided by the media manager. The multimedia 
application 48 is an application or other client of the media 
manager platform of the present invention. The architectural 10 
components within the media manager manage the protocol 
specifics and export a simpler programming interface up to 
the application 48. Issues such as timing, buffer 
management, bus management and communication protocol 
are hidden behind these simple functional interfaces. The 15 
application 48 also has access to the lower layers of the 
architecture and will of course be able to communicate 
directly with the hardware adaptation layer (HAL) and the 
host operating system 58. The host operating system is 
coupled to the other devices within the network, such as the 20 
camera 10, the VCR 12 and the settop box 13. For illustra- 
tion purposes, in this configuration the media manager of the 
present invention is implemented on the computer system 14 
of FIG. 1. 

The application interface object 50 serves as a proxy for 25 
the client application 48 within the media manager environ- 
ment. An applications programming interface is provided to 
allow the client applications 48 to access the basic services 
of the media manager. Access to more detailed or specific 
functionality provided by certain programming interfaces is 30 
also provided through the application interface object 50 
which provides the application 48 access to the local mes- 
senger 52. 

The local messenger 52 is one component of the messag- 
ing system integrated into the media manager. Preferably, 35 
this messaging system is the AV Messenger system. The 
local messenger 52 is the central hub of communications 
between all objects on a given node, when those objects 
exist in separate execution spaces. Essentially, the local 
messenger 52 is the inter- application communication model 40 
which is provided by the host operating system 58. The local 
messenger 52 is the bottleneck through which all messages 
between software modules pass. To achieve scrip lability, the 
local messenger 52 logs all messages as they pass through, 
keeping an internal database of all messages and their 45 
relevant data including address of destination, parameters, 
address of response and optionally, a time stamp for time- 
based scripting. 

The service registry 59 includes a reference to all addres- 
sable entities within the media manager 71. This registry 50 
includes a reference for each device control module (DCM) 
56, the DCM Manager 54, the data flow manager 64, the 
transaction manager 66, the data format manager 68, the bus 
manager 70 and the graphics manager 72. The service 
registry 59 also contains any number of service modules 60, 55 
as will be described below. The service registry 59 also 
contains a service registry database including references for 
all of the objects that are local to its node and at specific 
times references to remote objects as well. Each entry in the 
database refers to an addressable module and includes 60 
attached attributes, some of which are common to all entries 
and others which are specific to a type of module. Common 
attributes include such things as the module name and the 
local ID. Module-specific attributes will vary by the type of 
module. Once the entry exists in the service registry 65 
database, any number of attributes can be added to an entry. 
When a client application searches the database, the appli- 
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cation specifies a set of attributes to match and the service 
registry 59 searches the database, finding and returning all 
entries which match the specified criteria. If multiple can- 
didates are found during this search, the service registry 59 
will provide a list reference to the client application 48. The 
client application can then examine each of the candidate 
items in the list, to determine the items of interest. 

A client application 48 may have multiple outstanding 
search lists, each representing the results of a different 
search criteria. When the client application 48 needs to 
update a search list, in response to an event such as a bus 
reset in which different devices may be available, the 
application 48 passes the list reference back to the service 
registry 59 when making a search call. This allows the 
service registry 59 to update the existing list object, rather 
than disposing of it and reallocating a new one. 

The service modules 60 are modules which can be called 
to perform some set of services. The service modules 60 
perform a variety of services for client applications, includ- 
ing such services as data format, transport and control 
protocol translation. 

The DCM manager 54 is responsible for handling the 
group of DCMs 56 on its local node or for the devices within 
the controlling device's network. These responsibilities 
include the tasks of discovering, instantiating and disposing 
of all possible DCM candidates that are available to a given 
system. In addition, the DCM manager 54 communicates 
with other DCM managers on remote nodes, if any, to 
arbitrate for network-wide device and subdevice resource 
allocation and management. 

The DCM manager 54 works with the underlying oper- 
ating system services to get a raw list of available device 
node handles. The DCM manager 54 also provides an 
application programming interface for the client application 
48 to discover what subdevices, represented by DCMs 56, or 
other services are available within the devices on the net- 
work. A DCM 56 represents a device or subdevice available 
for allocation by the DCM manager 54. A DCM 56 can 
represent a physical device or a virtual device formed of 
subparts from different physical devices. The other available 
services are represented by virtual DCMs 56, which will be 
discussed below. The available DCMs will be dynamic, 
depending on the available physical devices on the IEEE 
1394-1995 serial bus. 

For each node, the DCM manager 54 does enough work 
to determine that it should create a DCM 56. This is done for 
all media-related devices which will be managed under the 
umbrella of the media manager of the present invention. For 
each media-related entity, the DCM manager 54 creates a 
generic DCM 56. Each DCM 56 then has the responsibility 
to make itself more device-specific, as will be described 
below. 

Device-specific DCMs provided from manufacturers can 
also be added into the DCMs 56. Device-specific DCMs can 
come from a variety of sources including an embedded 
read-only memory (ROM) within the device or some other 
storage mechanism such as the header of a disc or tape. The 
device-specific DCM may also be downloaded from an 
internet site or via a direct modem connection, if such 
capabilities are accessible to the media manager, or supplied 
from a disk or other storage medium. These alternatives are 
discussed in detail in the U.S. patent application Ser. No. 
09/092,703, filed on Jun. 4, 1998 and entitled "AMETHOD 
AND APPARATUS FOR INCLUDING SELF- 
DESCRIBING INFORMATION WITHIN DEVICES," 
which is hereby incorporated by reference. 
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The DCM manager 54 is responsible for adding and pieces of technology that make up an audio-visual device, 

disposing DCMs 56 at the appropriate times, and notifying such as the control protocol, physical connections and 

clients that DCMs 56 have been added or removed. The connection capabilities. A DCM 56 can also be created 

DCM manager 54 is also responsible for coordinating com- which does not represent a physical device, but represents a 

plex services among multiple DCMs 56. These complex 5 virtual device comprising a collection of functions or ser- 

services, such as command queuing of complex operations, vices ^at carry out a particular AV operation, 

require the DCM manager 54 to coordinate with multiple Physical devices and subdevices are individually acces- 

DCMs 56 to carry out these operations. sible P ieces of hardware. The media manager of the present 

~ . . » ... , invention uses accessible subdevices to support virtual 

T*e DCMs 56 each provide a device podding and devices tQ add enhanced bm to a nelwork of devices 

control protocol abstraction service by exporting a standard- io ^ ^ ^ J.^ ^ &rQ 

ized interface for device control up to the client apphcatiori from pieces of a variety 0 f available components. Preferably, 

^TVT, , , l°T P '° i ^ ^e virtual devices are created automatically when necessary 

by the DCMs 56 is divided into common A/V control and ^ ^ a r ed ^ MuimztivQl tne ^rtnal 

device-specificA/V control. The common A^ control com- deviccs afc d icall by rcque sting the service 

mands are common to virtually all devices having audio- 15 ^ ^ DCM m r ^ 

visual capabilities. The basic transport control functionality A A ,, • A « a *• *■ 

. j5 C4 „ . « a ad „r^A A ^ ' An AV action is a pre-defined action or activity such as 

such as Play, Stop, Fast Forward and Rewind commands are . . „ ^ (( , . „ J - 

. 1JJ ,- 7 '*_'. -ca/a; *i j "watch television or "record a movie, or any set of 

mcluded here. The device-specific A/V control commands . . . _ . \ t . M 

. , , - # . . „ nt *„„„, n f A/\/ user-defined actions involving the manipulation of devices 

include features common to a given category of A/V . n _. ™ °. /_ A Af 

• . i 4 , „ . j * ~i ■ -a, on by using the DCMs 56. The actions can be recorded for later 

devices, such as the Record command for devices with w * & v *• ~- 

' ..... , r * *u * * use by a user. An A/V action applications programming 

recording capability, and features that are specific to a . * . £ ■* 5 * u * 

\T . & ,^ * f • U(1 • f /l_ „ frt r interface is a way of modeling common actions that are 

certain model or group of devices. The lntormation tor r . j - - *?/ * 1, u , T - „ • 

j • - n a * ■ i * o-n™. k~ u„;n * performed with devices m an AV network, such as viewing 

device^specific functionality can either be built into a Y jju * . . ' „ j„„i- „ t 

. ■ F p.™, , . . . , . • t . j.„- :.„ir a recorded show, viewing a broadcast show, duplicating a 

device-specific DCM which is embedded in the device itseir, 4 ji-* ■ * * n t-. i/jf^i/r^n 

X_ , -u- a * ♦ « tape and listening to a compact disk. For example, if a VCR 

using the self -de scribing data structures mentioned 25 . * 6 . . . 5 „ nU . n „ M 5„ u™«* 

? , . j i j j ii. j is located in an upstairs bedroom within a user s house and 

previously, or it can be downloaded as a software upgrade . " f . . , . ... , „ _ , 

j r^ r r& is currently receiving a broadcast through the tuner and 

from the internet. displaying it on a television in the bedroom, the transport 

The media manager of the present invention employs mec hanism within the VCR is not being used. If the user 

protocol abstraction which means that the programming ^ ^ des j res to v i ew a recorded show on the television 

interface between the modules and the application is the downstairs, the media manager of the present invention will 

same, regardless of the kind of device and the controlling allow the user to place tne video tape j n me transport of the 

protocol being used. Accordingly, the application will use VCR in thc t, ec i r oom and watch the recorded show from the 

the same source code and message to cause an IEEE tape on me downstairs television. The data representing the 

1394-1995 VCR to record as it would use to cause a Video ^ recordcd show ^ transmitted from the upstairs VCR over the 

System Control Architecture (VISCA) VCR to record. This 1£EE i^ 94 _i 99 s serial bus network to the downstairs 

is true for the common A/V control commands and the television. This data transfer operation is controlled by the 

category-specific control commands; features that are truly me(Jia manager ^ me controlling device. Similar functions 

specific to a particular device will have a unique program- md virtual dcv j ces are achieved with tuners, demuxers, 

ming interface. 4Q transports, amplifiers, processors and other components and 

The DCM 56 is the mechanism by which self -describing subdevices. Accordingly, the user can maximize the func- 

data from a device is downloaded and presented to the user. tionality and capability of the devices within the network 

This requires the DCM 56 to analyze the self -describing us j n g the media manager to control their operation, 

information, by downloading and integrating modules and rjcM manager 54 keeps track not only of what 

managing the presentation of this information to the user 45 physical devices and subdevices are being used, but also 

through a host application. This allows a user to configure wnat virtual devices can be created from components and 

and control both the well-known and device -specific func- subcomponents that are currently available. The DCM man- 

tionality of devices on the network through the media ager 54 does tn is f or all of its locally managed devices and 

manager interface. The preferred presentation of user inter- f or software services available on the host platform on 

face data and access to custom functions of the device is 5Q wn ich it is executing. The DCM manager 54 also provides 

described in the U.S. Provisional Patent Application Ser. No. tne programming interfaces for a client application 48 to 

60/054,199, filed on Jul. 30, 1997 and entitled "METHOD inquire about the virtual devices that can be created based on 

FOR DESCRIBING THE HUMAN INTERFACE FEA- ^ t rcsour ces available on the network, as well as what AV 

TURES AND FUNCTIONALITY OF AV/C-BASED actions can be curre ntly performed. The DCM manager 54 

DEVICES," which is hereby incorporated by reference. 55 ^ Q cnsurcs that virtual devices get added to the service 

Together, the DCM manager 54 and the DCMs 56 per- registry 59 at the appropriate times, 

form command queuing of AV commands to be executed, The applications programming interface provided for the 

allowing the DCM 56 to deal with all device peculiarities, DCMs 56 is designed to allow the client applications 48 to 

such as the need to perform a pre-roll to account for discover what features and capabilities are available within 

mechanical latency of a device. The DCM manager 54 and 60 mc devices in the network and then work with those devices 

the DCMs 56 in coordination with other parts of the media a s necessary. This programming interface includes device 

manager also provide the ability to specify device control control, device management, connection management and 
actions that are taken at specific times and as the result of management of the self -describing device implementation, 

certain conditions. Each of the DCMs 56 have the responsibility to convert from 

The DCMs 56 make up a large part of the overall 65 a generic DCM to a device or protocol specific DCM by 

architecture of the media manager of the present invention. determining the type of device it is managing. This requires 
The DCM 56 provides an abstraction for all of the various that the DCM examine the self-describing device data from 
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the device, if any is present, and analyze any other infor- 
mation that may be available. The DCMs 56 also have the 
responsibility to provide access to the self -describing device 
information data for the device being managed, including 
the device image, a product name string and functional 
descriptors to other devices and components. The DCM 56 
is further responsible for providing a consistent interface for 
device control, including the complex services such as 
command queuing. Carrying out these commands requires 
coordination with the host operating system 58 for device 
control protocol usage, including packaging, sending, pro- 
cessing protocol-specific commands and responses via the 
protocol driver and other operating system provided support 
mechanisms. 

Each DCM 56 also monitors the device it is controlling 
and provides extended notification support to the necessary 
components and applications. All normal events generated 
by the device go through the DCM 56 for the appropriate 
device, to the event manager 62 and to all interested client 
applications 48. In addition to supporting the AV/C device 
notification events, many situations may not be supported 
explicitly in either the AV/C protocol, in a given device or 
other control protocol. Depending on the capabilities of the 
device and its control and communications protocols, it is 
possible to provide extended support for such events which 
do not trigger actual event messages. The DCM 56 watches 
the device for this kind of activity and posts an event to the 
event manager 62. 

Each DCM 56 is also responsible for managing them- 
selves in terms of the outside entities which are making use 
of the data from the device under their control and the 
entities that are controlling them. This includes support for 
resource sharing and resource queuing. Resource queuing 
allows an entity to reserve a busy DCM for its use, as soon 
as the DCM 56 is available. As soon as the DCM 56 is 
available, it will then notify the entity. 

The DCMs 56 also preferably maintain a presence during 
environmental changes allowing the DCM aod clients to 
support both on-line and off-line states. This allows the 
DCMs 56 to quickly re-establish the services of a device 
once it comes on-line again. 

Within the media manager of the present invention, the 
DCMs 56 are responsible for controlling the available 
devices and subdevices. The DCMs 56 provide access to the 
capabilities of the device, both general and device-specific. 
In an alternate embodiment of the present invention, each 
device, as part of the self-describing data, has an embedded 
DCM, ensuring that the software is always available regard- 
less of where the device is taken. In a further alternate 
embodiment, the DCM for a specific device is obtained from 
the device manufacturer or a third party over the internet or 
provided on a media device, such as a floppy disk. In each 
of the above embodiments, the DCM 56, once downloaded 
can be stored in a variety of locations. Preferably, the DCM 
56 is stored on the device it controls. However, the DCM 56 
can also be stored in any appropriate location. In an alternate 
embodiment of the present invention, the DCM 56 is written 
in common byte or script code format, such as Java or Java 
Script, supported by the host platform. The DCM 56 is then 
uploaded to the host device and executed there. 

Hie event manager 62 broadcasts all event notifications 
within the network to all interested parties. The event 
manager 62 acts as a central location for all modules within 
its node to register for notification when events occur in that 
node. The event manager 62 maintains an event notification 
list data structure which is a list of the defined event types 
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and the destination identifiers of all devices which have 
registered for notification of each type of event. The devices 
each register with the event manager 62 for each event type 
that is of interest to them, providing their client identifier and 

5 a token value to be passed back to them when the event 
message is broadcast. An event is an actual occurrence of 
some action and a message from a device which is addressed 
to multiple destinations. 
The event manager 62 does not usually generate events, 

10 but accepts and broadcasts events posted by other compo- 
nents with the media manager. When broadcasting events to 
client applications 48 in remote nodes, the event manager 62 
makes use of the broadcast manager 74. The event manager 
62 handles the interaction with the user and informs the 

15 appropriate devices accordingly. The event manager 62 
informs the-DCMs 56 of what user input is occurring 
through the interface at the control software level, so that the 
DCMs 56 can handle their physical devices appropriately. A 
DCM 56 controlling its device from a remote location will 

20 need to receive messages indicating what the user is doing 
and will need to send appropriate messages to its device. The 
event manager 62 supports the execution of remote DCMs 
56 by means of the messaging system and well-defined 
event messages. The well-defined event messages include 

25 device administration, such as a new_device message gen- 
erated when a device is added to the network, and user 
interaction. The user interaction messages support the pre- 
ferred graphical user interface model as described in the 
U.S. Provisional Patent Application Ser. No. 60/054,199, 

30 filed on Jul. 30, 1997 and entitled "METHOD FOR 
DESCRIBING THE HUMAN INTERFACE FEATURES 
AND FUNCTIONALITY OF AV/C-BASED DEVICES/' 
which is hereby incorporated by reference. In addition to 
well-defined event messages, any two DCMs or software 

35 modules can also define custom or private messages. 

The graphics manager 72 manages the embedding of 
remote device controls into a controlling application and 
supports the remote presentation of self-describing data 
information by the DCMs 56. The graphics manager 72 

40 provides a programming interface that allows the DCMs 56 
to arbitrate for screen space and to work within a shared 
graphics environment. This allows the specific capabilities 
of a device to be presented to and accessed by the user 
through the interface of the controlling software. 

45 The data format manager 68 manages the format of the 
data flowing between devices. This includes the ability to 
plug into the resident media manager for data format con- 
version as part of the buffer management and data format 
process. Most of the data format conversions are done 

50 transparently on behalf of the client application, based on 
knowledge of the source and destination of the data. Other 
data transformations require the client application 48 to set 
up a format conversion process. Preferably, the format 
conversion is performed in-line while the data is being 

55 transmitted. Alternatively, the format conversion is per- 
formed as either a pre or post processing task to transmission 
of the data. The data format conversion services available on 
a given platform are stored in the service registry 59. In 
addition to using the registry to find services, the data format 

60 manager 68 is responsible for instantiating the service 
modules and registering them with the service registry 59. 

The data flow manager 64 works with the bus manager 70 
to provide services to assist with routing data from source to 
destination, which may include many nodes in between. In 

65 the event that the source and destination device involve 
different data types, or are separated by a barrier, the data 
flow manager 64 will work with the data format manager 68 
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and the service registry 59 to handle automatic or requested 
data translation services as well. During the transfer of 
isochronous data, the data flow manager 64 provides buffer 
allocation and management services. Buffer management 
includes the provision for a consistent notification mecha- 5 
nism to inform the client application when data is available 
for processing. While isochronous data is flowing into the 
client application 48, various memory buffers are filled with 
the data. The data flow manager 64 informs the client 
application 48 when each buffer is filled so that it can handle 10 
the data acquisition process from the buffer. In addition, 
buffer management is simplified for client applications by 
having the appropriate service modules partition memory in 
a manner that is optimized for the data being captured. This 
includes separating the allocated memory into scan line or 15 
frame-sized segments for a stream of video data or the 
optimum segment sizes for raw audio and MIDI data. 

A flow diagram of the steps involved in setting up a data 
transfer between two devices using the media manager of 
the present invention is illustrated in FIG. 5. The method 20 
starts at the block 100. When a client application 48 desires 
to establish a connection between two devices for a transfer 
of data, the application calls the 
EstablishExtemalConnection( ) method of one of the two 
DCMs 56 that represent the two devices and passes the 25 
modulelD value of the other device's DCM 56 as a param- 
eter. (Block 102) The DCM 56 that was called then calls the 
data flow manager 64 to assist with making the connection 
and passes both the source and destination DCM modulelDs 
as parameters. (Block 104) The data flow manager 64 then 30 
analyzes the source and destination IDs to determine that 
they are in different nodes. (Block 106) The data flow 
manager 64 next obtains the topology map of the network 
from the bus manager 7 of the source node. (Block 108) The 
data flow manager 64 then analyzes the topology map to find 35 
the destination node and determine if it is on the topology 
map. (Block 110) If the destination node is on the topology 
map, then the data flow manager 64 jumps to the Block 118 
to determine the best route for the data transfer. If the 
destination node is not on the topology map, then the data 40 
flow manager 64 obtains the destination DCM from the 
service registry 59 in order to determine the transmission 
protocol for that node. (Block 112) The data flow manager 
64 then finds the appropriate transmission protocol service 
module and sets up the appropriate conversion process. 45 
(Block 114) It is then determined if multiple transports need 
to be bridged. (Block 116) If multiple transports do need to 
be bridged then the data flow manager 64 jumps back to the 
Block 114 and obtains another transport conversion module. 
Otherwise, the data flow manager 64 then analyzes the 50 
connection paths to determine the best route for the data 
flow. (Block 118) The data flow manager 64 then analyzes 
the input data formats for the source and the destination 
nodes in order to determine if a conversion is necessary. 
(Block 120) If a conversion is necessary, the data flow 55 
manager 64 obtains the appropriate format converter from 
the service registry 59, based on the input and output format 
and sets up the conversion process. (Block 122) Otherwise, 
the data flow route is complete and the data transfer between 
the two devices can begin. (Block 124) 60 

The bus manager 70 abstracts the underlying device 
interconnection mechanism, providing a common set of 
programming interfaces to describe the capabilities of the 
bus architecture. In the preferred embodiment of the present 
invention, the devices are connected by an IEEE 1394-1995 65 
serial bus. For the IEEE 1394-1995 serial bus network, the 
bus manager 70 resides on the top of the IEEE 1394-1995 
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HAL layer that is provided by the host operating system 58. 
The bus manager 70 then helps to generalize the bus 
management activities up to the media manager of the 
present invention. The bus manager 70 notifies the client 
applications 48 when bus reset activity occurs by sending 
out bus reset notifications through the event manager 62 and 
providing complete information about how the environment 
has changed. The client applications receiving this informa- 
tion are provided with information about the devices which 
may have suddenly disappeared and the devices which have 
suddenly become available after the bus reset. 

The bus manager 70 also provides topology maps, speed 
maps and other environment descriptions to client applica- 
tions 48. Information from the topology map is used to build 
a user interface that helps the user understand the connection 
of the devices and how certain features may be used. This 
information is also used to provide automatic data routing as 
described above in relation to the data flow manager 64. The 
speed map is used to analyze the current connection scheme 
and to give the user helpful suggestions for improving the 
performance of devices on the network by rearranging the 
way that devices are connected. The bus manager 70 also 
provides atomic-level data communications services for two 
nodes or software modules within the nodes, to send bytes 
to each other in a preferred format or protocol. This protocol 
is built on top of those atomic communications functions. 

After a bus reset or change notification of the bus, the bus 
manager 70 assigns new ID values to all devices which have 
just appeared and determines what devices have disap- 
peared. The bus manager 70 then invokes the DCM manager 
54 to create new DCMs 56 for the devices which have just 
appeared and posts a bus change notification to the event 
manager 62, which will notify all registered clients about the 
bus reset. This notification provides enough information for 
the client applications 48 to determine what devices have 
changed on the bus. 

The transport adaptation modules 78 take care of pack- 
aging message data before it is passed on to the HAL for 
actual transmission to the destination device. The HAL is at 
the lowest layer of the media manager of the present 
invention. This layer provides a common programming 
interface upward to clients such as the DCMs 56 and any 
other entities that need to communicate with it. The transport 
adaptation modules 78 use the atomic messaging functions 
of the bus manager 70, as described above. 

As described above, the DCMs 56 provide a protocol 
abstraction service, by exporting a standardized interface for 
device control up to the multimedia application 48. The 
programming interface provided by these components is 
divided into a common audio/video control level and a 
device -specific control level. The common audio/video con- 
trol level provides an interface for common commands, 
including the basic transport control functionality, such as 
Play, Stop, Fast-Forward and Rewind commands. The 
device-specific control level provides an interface for 
device-specific commands, including features common to a 
given category of devices, such as Record for devices with 
recording capability, and features which are specific to a 
certain device or group of devices. The protocol abstraction 
service provided by the DCMs 56 ensures that the program- 
ming interface between the modules and the application 48 
is always the same, regardless of the kind of device and the 
controlling protocol being used. This feature allows a great 
degree of flexibility for the application and the user. The 
DCMs 56 also provide a user input event abstraction model, 
so that client applications can display graphical user inter- 
face elements and send standard user event messages to the 
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DCM 56 as the user interacts with the graphical user 
interface elements, as described in U.S, Provisional Patent 
Application Ser. No. 60/054,199, referred to above. 

The media manager of the present invention provides data 
flow management and other services. The media manager 
acts as an extension of the hosting operation system 58 and 
provides a variety of services to the other components of the 
media manager platform as well as to the client application 
48. The media manager manages and organizes the DCMs 
56. The media manager discovers and initializes the DCMs 
56 which are appropriate for the applications present, while 
disposing of the unnecessary DCMs 56. The media manager 
follows a specific sequence each time the system is booted, 
or any time the system could possibly change, such as when 
the IEEE 1394-1995 bus is reset. The media manager also 
provides a wrapper around the particular dynamically linked 
library solution that is used on the host operating system 58. 
This allows the best dynamically linked library to be used to 
implement modules on a given operating system, while still 
maintaining a consistent interface to outside applications. 

The media manager is also responsible for managing the 
flow and format of data transfer operations between the 
devices on the network. When managing the flow of data, 
the media manager will allocate and manage the appropriate 
buffers in a fashion independent of the operating system 
being used. 

The media manager also provides high-level protocol 
management of the IEEE 1394-1995 bus environment. In 
order to fully support dynamic device actions such as hot 
plugging up to the user level, the applications and devices 
need to be aware of changes to the IEEE 1394-1995 bus 
environment The media manager through the bus manager 
70 and the event manager 62 is responsible for informing the 
applications and devices that bus reset activity has occurred 
on the IEEE 1394-1995 bus, by sending out bus reset 
notifications and providing complete inform atioa about how 
the environment has changed. Hie media manager also 
provides topology maps and other environment descriptions 
to the applications and devices also through the bus manager 
70. The topology map illustrates the connections between 
devices within the IEEE 1394-1995 network. Information 
derived from the topology map is used to build a human 
interface which helps the user understand how the devices 
are connected and how certain features may be used. 

The application service modules 60 provide a level of 
services between the host operating system 58 and the 
application 48 in order to provide basic functionality for the 
application 48 independent of the specific operating system 
being used. This functionality includes providing memory 
allocation and disposal routines which are more robust than 
the basic functions available in most operating systems and 
providing device configuration and control modules which 
are self-contained, stand-alone modules for providing all 
user interface and interaction management when invoked. 

The transport adaptation modules 78 provide a common 
programming interface to the device control modules 50 and 
to the application 48, taking care of bringing the protocol 
capabilities up through the host operating system 58. The 
internal design and implementation of the system level 
interface block 50 takes advantage of the specific host 
operating system architecture being used in order to realize 
the IEEE 1394-1995 functions available to the application 
48. 

The media manager platform of the present invention 
includes the DCMs 56, the application service modules 60 
and the system level interface for IEEE 1394-1995 bus 
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protocol provided by the transport adaptation modules 78. 
During normal operation, the application 48 will communi- 
cate with all of these components. When communicating 
with the DCMs 56, the application 48 will use a single 

5 programming interface. When communicating with the 
application service modules 60, the application will also use 
a single programming interface. 

A client application 48, as described above and illustrated 
in FIGS. 3 and 4, is an entity which resides above all the 

1° other components in terms of the architecture of the media 
manager platform of the present invention. For the comple- 
tion of a majority of its required tasks, the application 48 will 
communicate with the DCMs 56 and the application service 
modules 60 which are present via the local messenger. For 

1 5 the times when it is necessary, the application 48 has access 
to the lower levels of the architecture through the host 
operating system 58. 

Upon startup of the client application 48, the client 
application 48 must initialize and register with the media 

20 manager. The client application 48 initializes the media 
manager in order to make sure that the media manager is up 
and running and ready to serve the application 48. The client 
application 48 registers with the media manager in order to 
give the media manager all of the necessary information for 

25 interaction with the application 48 and to register itself with 
the messaging system. When starting up, generally an appli- 
cation 48 must make sure that the host operating system has 
been initialized, that a minimum level of services are avail- 
able and. that it has the necessary amount of memory 

30 available to run. These steps are performed for the applica- 
tion by the media manager after the application 48 initializes 
the media manager. 
When starting up, a client application 48 follows the steps 

35 illustrated in the flow chart of FIG. 6. The application 48 
starts up at the step 140. After starting up, the application 48 
initializes the media manager. In the preferred embodiment 
of the present invention the application initializes the media 
manager by making the following call: 

40 cir-SMM_JnitializG 

When initialized, the media manager will allocate the nec- 
essary memory and system services to support the applica- 
tion 48. 

45 After initialization of the media manager is complete, the 
application 48 then registers with the media manager at the 
step 144. This step of registering allows the application 48 
to provide the media manager with specific information that 
the media manager will need in order to properly support the 

50 application 48. For example, the application 48 must provide 
the address of a callback routine for notification of signifi- 
cant events related to the environment, including IEEE 
1394-1995 bus resets, asynchronous transaction completion 
and triggers when memory buffers have been filled with a 

55 specified amount of isochronous data. The step of registering 
is completed by the following instruction: 

SonyErrorResultType SMM_Register Client 
(SMMClientldentifierType* the ClientID, SMM- 
BusEventNotificationUPP 

60 clientBusEventNotificationCallback, void* 
clientBusEventCallbackD ata); 
The parameter the ClientID is a unique identifier created by 
the media manager for the application. In future communi- 
cation with the media manager, the application 48 will be 

65 required to pass this identifier back in, such as when it is 
closing down and unregistering with the media manager. 
The parameter clientBusEventNotificationCallback is an 
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appropriately formatted reference to the callback function 
that the application 48 will implement. The application 48 is 
not required to implement such a callback function if the 
application 48 does not need to know about dynamic 
changes which may occur to the network environment. If the 
application 48 does not implement this callback function, 
then the application will pass a NIL value for this parameter. 

The parameter clientBusEventCallbackData can be any 
value that the application 48 will require access to in the 
callback routine. Normally, this value will be a pointer to a 
block of memory such that when the media manager invokes 
the callback function, it will pass this value back to the client 
application 48, allowing the application 48 to then access 
global storage or other appropriate data. 

To complete the step of registering with the media 
manager, the application 48 must also implement the noti- 
fication callback function using the following interface: 

pascal void (*SMMBusEventNotificationProcPtr)(void 
*clientData, SMMBusEventType busEventlndicator, 
SMMBusEventRecPtr busEventlnfo); 

The parameter clientData is the clientBusEventCallback- 
Data parameter that was passed in to the registration func- 
tion. The parameter busEventlndicator is an enumerated 
data type which indicates what kind of event the application 
is being notified of. The specified events include a bus reset, 
when a device is plugged into or unplugged from the 
network, the completion of an asynchronous transaction and 
when a specified buffer is full during an isochronous transfer 
of data. The parameter busEventlnfo provides a data struc- 
ture that contains relevant information for the particular 
event. 

After completing the step of registering with the media 
manager, the application 48 then will obtain the available 
DCMs 56 at the step 146. By obtaining the available DCMs 
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The parameter userData of the callback function is the 
means of transferring data between the media manager and 
the application 48. The application 48 will define its own 
data structure, allocate the memory for one of these struc- 

5 tures and pass the address of that structure to the media 
manager. That address is then passed back in this callback 
function allowing the application 48 to access that data 
structure for the purpose of copying information into it. 

10 The parameter devicelndex of the callback function is the 
index value of the loop which the application 48 enters to 
obtain information about the available DCMs 56. The loop 
is bounded by the number of available DCMs 56. This 
parameter is passed back to the application 48 in the callback 

15 function so that the application 48 can save this parameter 
along with the other information passed into the callback 
function. This index value is useful in other calls to the 
media manager by the application 48, when inquiring about 
a specific DCM 56. In addition, this index value will be used 

20 when notifying the application 48 that a device has disap- 
peared after it was unplugged or disconnected from the 
network. The application 48 will store this index value for 
each DCM 56 within a dedicated field in its private data 
structure. 

25 The parameter devicelnfo of the callback function is a 
pointer to a data structure labeled SonyAVDeviceRec, in 
which the media manager stores the DCMs 56 for retrieval 
by the application 48. The format of this data structure is 

30 known to both the application 48 and the media manager. 
Once a DCM 56 is stored within this data structure, the 
application 48 will then copy the appropriate information 
from the data structure to its own private data structure. The 
data structure SonyAvDeviceRec is defined in Table I below: 



TABLE I 



typedef struct SonyAVDeviceRec 

unsigned long device ID; //SMMDevicelDType? 

unsigned long busGeneration; 
SONY_DeviceModuleRefiype controlModuleReference; 
unsigned long reservedl; 
unsigned long reserved^; 
} SonyAVDeviceRec,*SonyAVDeviceRecPtr,* *SonyAVDeviceRecHdl; 



56, the application 48 will know the other types of devices 
which are coupled within the network. This step is com- 
posed of a series of sub-steps. An iterative callback model is 
used as the method of data transfer for transferring the data 
to the application 48. The client application 48 first gives the 
media manager an address of a callback function. The 
application 48 then enters a loop and repeatedly requests 
information about the next module from the media manager 
until there are no remaining DCMs. The media manager 
prepares a data structure with the necessary information and 
transfers it to the application 48 via the callback function. 
Once the information about each specific DCM 56 is 
received, the application 48 then copies the information 
which it requires. This process is repeated until all of the 
available DCMs 56 have been received by the application 
48. Within an alternate embodiment of the present invention, 
the client application queries the system registry, requesting 
a handle to each of the available DCMs 56. 

The preferred callback function which the application 48 
must implement to obtain the available DCMs 56 is defined 
as follows: 

void DeviceInfoCallbackRoutine(void *userData, 
SMMDevicelndexType devicelndex, SonyAvDevice- 
RecPtr devicelnfo) 



The parameter devicelD is the identifier of a DCM 56 and 
correspondingly of a device. This identifier is used by the 
application 48 whenever it wants to communicate with a 
DCM 56 or when the application 48 requests services from 

5Q the media manager regarding a specific device. 

The parameter busGene ration is a value which changes 
after each bus reset action. After each bus reset, when 
devices are added or removed, certain information about the 
bus and the connected devices will change. Each time that 
the IEEE 1394-1995 bus is reset, the value of the parameter 

55 busGeneration is updated. 

The parameter controlModuleReference is a reference to 
the DCM 56 that is associated with the specified device. This 
reference is used when the application 48 requires the media 
manager to act on its behalf in transactions with the module. 

60 The application 48 will next request that the media 
manager generate a list of available DCMs 56 and the 
number of modules within that list using the following 
function call: 

SonyErrorResultType SMM_ 
65 FindDevice ControlModules 

(SMMDeviceListRefiype* theDeviceList, unsigned 
long deviceAttributes, short* numAVDevices) 
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The parameter theDeviceList includes the address where the 
list of available DCMs 56 is stored and is generated and 
returned by the media manager. The application will declare 
a local variable of this type and pass the address of that 
variable to this function. 

The parameter device Attributes includes a set of bitwise 
flags which the application 48 uses to specify the types of 
DCMs 56 which should be returned. For example, the 
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application-defined data structure. This reference is passed 
back to the application 48 in the callback routine and the 
application 48 will then transfer any needed information 
from the media manager to this data structure. 

The entire preferred sequence of the step to obtain the 
available DCMs 56 is listed in Table II below: 



TABLE II 



SMMDeviceListRefType theDeviceList -» NULL; 
if (nil !=theDeviceList) 

err = SMM_FindAllDeviceControlModules(& theDeviceList JcActiveDevices + klnactiveDevices, 

&gNumAVDevices); 

if (noErr == err) 

{ 

gAVDev ice List = NewHandle(O); 

//Prepare the callback function for the media manager: 
theDevicelnfo Callback = NewSMMDeviceControlModuleIteratorProc(DeviceInfoCa]lbackRoutine); 
if ((nil I- theDevicelafoCallback) && (nil I- gAVDeviceList) ) 
{ 

for(loop = 0; loop < gNumAVDe vices; toop++) 

err - SMM_GetDeviceControlModuleInfo (theDeviceList, loop, 0, 

theDevicelnfoCallback, gAVDeviceList); 

} 

DisposeRoutineDcscriptor(theDeviceInfoCallback); 

} 

else 

en - -1; 

void DcvicelnfoCallbackRoutine (void "userData, SMMDevicelndexType devicclndex, SonyAVDcviccRECPtr 

devicelnfo) 

{ 

//Copy any information that [ care about from the devicelnfo data structure 
//ovei to my private data referenced by useiData: 
(myPrivateRccordPtr) uscrData->deviccID « devicelnfo- >deviccID; 

} 



35 



application 48 may only wish to know about the active 
devices connected to the network. When certain flag values 
are specified the media manager will filter the list for only 
the devices meeting the criteria, before the list is returned to 4Q 
the application 48. The application 48 can specify that the 
list include all identifiable devices, only devices that are up 
and running, only devices that are plugged in but have their 
power switch turned off or only snoozing devices. 

The parameter numAVDevices includes the number of <5 
DCMs 56 in the list that is returned to the application 48. 
The application 48 uses this number as the upper boundary 
of the iteration loop to obtain the DCMs 56. 

The application 48 prepares the callback function address 
and then enters a loop to repeatedly call the media manager 
until the information on all of the DCMs 56 within the list 
is obtained. On each pass through the loop, the application 
48 makes one call to the following function: 

pascal SonyErrorResultType SMM_ 55 
GetDeviceControlModulelnfo 
(SMMDeviceListRefType theDeviceList, SMMDevi- 
celndexType whichDevice, unsigned long reserved, 
SMMDeviceControlModulelteratorUPP 
theDeviceListCallbackFunction, void *userData) 60 
The parameter theDeviceList is the list reference that was 
returned from the function call 
FindAllDeviceControlModules( ). The parameter whichDe- 
vice specifies which of the DCMs 56 that the application 48 
is requesting information about. The parameter theDevice- 65 
ListCallbackFunction includes the prepared callback func- 
tion address. The parameter userData is a reference to an 



After the available DCMs 56 are obtained by the appli- 
cation 48, the application 48 will then obtain device specific 
information at the step 68. The DCM information returned 
by the media manager is system level information which 
includes the unique identifier for each device and protocol- 
specific information such as the bus generation for the IEEE 
1394-1995 devices. In order to obtain the device specific 
information such as status, descriptive name string and an 
image of the device, the application 48 must communicate 
with the device through the appropriate DCM 56. By com- 
pleting the steps illustrated in FIG. 6 and described above, 
the application 48 will have completed its startup routine 
and is now ready for operation. 

While the application 48 is operating it will be handling 
user and system level events and messages including receiv- 
ing control inputs, as well as messages from other processes, 
the host operating system and the media manager. 

The present invention has been described in terms of 
specific embodiments incorporating details to facilitate the 
understanding of principles of construction and operation of 
the invention. Such reference herein to specific embodi- 
ments and details thereof is not intended to limit the scope 
of the claims appended hereto. It will be apparent to those 
skilled in the art that modifications may be made in the 
embodiment chosen for illustration without departing from 
the spirit and scope of the invention. Specifically, it will be 
apparent to those skilled in the art that while the preferred 
embodiment of the present invention is used to manage 
devices coupled together within an IEEE 1394-1995 serial 
bus structure, the present invention can also be implemented 
to manage devices within other bus structures. 
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We claim: 

1. A method of managing operation of and communica- 
tion between a network of devices comprising: 

a. maintaining a control module for each device in the 
network, wherein the control module includes the capa- 5 
bilities of the device and any subdevices within the 
device and further wherein the control module is 
responsible for control of the device; 

b. providing an interface to a user through which a task to 
be completed is requested by the user; io 

c. determining appropriate devices and subdevices 
required for completion of the task by searching the 
control modules; and 

d. completing the task by instructing appropriate control 
modules to provide instructions to the appropriate 15 
devices and subdevices. 

2. The method as claimed in claim 1 further comprising 
controlling data flow between the appropriate devices and 
subdevices. 

3. The method as claimed in claim 2 further comprising: 20 

a. obtaining a topology map of the devices within the 
network; and 

b. determining a best route for the data flow by analyzing 
the topology map. 25 

4. The method as claimed in claim 3 further comprising: 

a. determining if conversion of data flowing between the 
appropriate devices and subdevices is necessary; and 

b. converting the data flowing between the appropriate 
devices and subdevices into a proper format if data 30 
conversion is necessary. 

5. The method as claimed in claim 4 wherein the network 
is an IEEE 1394 serial bus network. 

6. The method as claim din claim 1 wherein the control 
module is embedded in a corresponding device in the 35 
network. 

7. The method as claimed in claim 1 further comprising 
downloading the control module for a corresponding device 
in the network. 

8. The method as claimed in claim 1 wherein the control 40 
module is stored and executed remotely from a correspond- 
ing device in the network. 

9. The method as claimed in claim 1 wherein the control 
module is in a platform neutral format. 

10. The method as claimed 9 wherein the platform neutral 45 
format is Java. 

11. The method as claimed in claim 1 wherein the control 
module provides automatic control of a corresponding 
device in the network. 

12. An apparatus for controlling operation of and com- 50 
munication between a network of devices comprising: 

a. a plurality of control modules, each representing a 
device in the network, wherein each control module 
includes capabilities of a corresponding device and any 
subdevices within the corresponding device and further 55 
wherein the control module is responsible for control of 
the device; 

b. an interface configured to communicate with a user, 
wherein a task to be completed is requested by the user 
through the interface; and 60 

c. a control circuit, coupled to the plurality of control 
modules, to the network and to the interface, configured 
to determine appropriate devices and subdevice 
required for completion of the task by searching the 
control modules and to complete the task by instructing 65 
appropriate control modules to provide instructions to 
the appropriate devices and subdevices. 
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13. The apparatus as claimed in claim 12 wherein the 
control circuit is further configured to control data flow 
between the devices within the network. 

14. The apparatus as claimed in claim 13 further com- 
prising a bus manager circuit, coupled to the control circuit, 
configured to obtain a topology map of the devices within 
the network and to determine a best route for the data flow 
by analyzing the topology map. 

15. The apparatus as claimed in claim 14 wherein the 
control circuit is also configured to convert the data flowing 
between the appropriate devices and subdevices into a 
proper format if data conversion is necessary. 

16. The apparatus as claimed in claim 15 wherein the 
control circuit is also configured to implements pre-defined 
actions allowing users to access basic functionality of the 
devices in the network. 

17. The apparatus as claimed in claim 16 wherein the 
control circuit is also configured to monitor and record user 
activity and to create custom, user-defined actions. 

18. The apparatus as claimed in claim 15 wherein the 
network is an IEEE 1394 serial bus network. 

19. The apparatus as claimed in claim 12 wherein one or 
more of the control modules are embedded within the 
corresponding devices. 

20. The apparatus as claimed in claim 12 wherein one or 
more or the control modules are downloaded for each 
corresponding device. 

21. The apparatus as claimed in claim 12 wherein one or 
more of the control modules are stored and executed 
remotely from the corresponding devices. 

22. The apparatus as claimed in claim 12 wherein one or 
more of the control modules are in a platform neutral format. 

23. The apparatus as claimed in claim 22 wherein the 
platform neutral format is Java. 

24. The apparatus as claimed in claim 12 wherein one or 
more of the control modules provide automatic control of 
the corresponding devices. 

25. An apparatus for controlling operation of and com- 
munication between a network of devices comprising: 

a. means for representing each device in the network 
including the capabilities of the device and any subde- 
vices within the device and further wherein the means 
for representing is responsible for control of the device; 

b. means for interfacing for communicating with a user, 
wherein a task to be completed is requesting by the user 
through the interface; and 

c. means for controlling coupled to the means for 
representing, to the network and to the means for 
interfacing for determining appropriate devices and 
subdevices required for completion of a task by search- 
ing the means for representing to provide instructions 
to the appropriate devices and subdevices. 

26. The apparatus as claimed in claim 25 wherein the 
means for controlling further controls data flow between the 
devices within the network. 

27. The apparatus as claimed in claim 25 further com- 
prising a means for managing the network coupled to the 
means for controlling for obtaining a topology map of the 
devices within the network and determining a best route for 
data flow between the appropriate devices and subdevices by 
analyzing the topology map. 

28. The apparatus as claimed in claim 25 wherein the 
means for controlling also converts data flowing between the 
appropriate devices and subdevices into a proper format if 
data conversion is necessary. 

29. The apparatus as claimed in claim 25 wherein the 
means for controlling implements pre-defined actions allow- 
ing users to access basic functionality of the devices in the 
network. 
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30. The apparatus as claimed in claim 25 wherein the 
means for controlling also monitors and records user activity 
and creates custom, user-defined actions. 

31. The apparatus as claimed in claim 25 wherein the 
network is an IEEE 1394 serial bus network. 

32. The apparatus as claimed in claim 25 wherein the 
means for representing each device is embedded in a cor- 
responding device. 

33. The apparatus as claimed in claim 25 wherein the 
means for representing each device is downloaded for each 
corresponding device. 

34. The apparatus as claimed in claim 25 wherein the 
means for representing each device is stored and executed 
remotely from a corresponding device. 

35. The apparatus as claimed in claim 25 wherein the 
means for representing each device is in a platform neutral 
format. 

36. The apparatus as claimed in claim 35 wherein the 
platform neutral format is Java. 

37. The apparatus as claimed in claim 25 wherein the 
means for representing each device provides automatic 
control of a corresponding device. 

38. A method of managing operation of and communica- 
tion between a network of devices comprising: 

a. maintaining a control module for each device in the 
network, wherein the control module includes the capa- 
bilities of the device and any subdevices within the 
device and further wherein the control module is 
responsible for control of the device; 
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b. providing an interface to a user through which a task to 
be completed is requested by the user; and 

c. determining appropriate devices and subdevices 
required for completion of the task by searching the 
control modules. 

39. The method as claimed in claim 38 further comprising 
completing the task by instructing appropriate control mod- 
ules to provide instructions to the appropriate devices and 
subdevices. 

40. The method as claimed in claim 38 further comprising 
controlling data flow between the appropriate devices and 
subdevices. 

41. The method as claimed in claim 40 further compris- 
ing: 

a, obtaining a topology map of the devices within the 
network; and 

b. determining a best route for the data flow by analyzing 
the topology map. 

42. The method as claimed in claim 38 further compris- 
ing: 

a. determining if conversion of data flowing between the 
appropriate devices and subdevices is necessary; and 

b. converting the data flowing between the appropriate 
devices and subdevices into a proper format if data 
conversion is necessary. 

43. The method as claimed in claim 38 wherein the 
network is an IEEE 1394 serial bus network. 
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MEDIA MANAGER FOR CONTROLLING 
AUTONOMOUS MEDIA DEVICES WITHIN A 

NETWORK ENVIRONMENT AND 
MANAGING THE FLOW AND FORMAT OF 
DATA BETWEEN THE DEVICES 

FIELD OF THE INVENTION 

The present invention relates to the field of managing 
applications and devices within a network environment. 
More particularly, the present invention relates to the field of 
managing the operation of and the communication between 
devices within a network environment. 

BACKGROUND OF THE INVENTION 

The IEEE 1394-1995 standard, "1394-1995 Standard For 
A High Performance Serial Bus," is an international stan- 
dard for implementing an inexpensive high-speed serial bus 
architecture which supports both asynchronous and isoch- 
ronous format data transfers. Isochronous data transfers are 
real-time transfers which take place such that the time 
intervals between significant instances have the same dura- 
tion at both the transmitting and receiving applications. Each 
packet of data transferred isochronously is transferred in its 
own time period. An example of an ideal application for the 
transfer of data isochronously would be from a video 
recorder to a television set. The video recorder records 
images and sounds and saves the data in discrete chunks or 
packets. The video recorder then transfers each packet, 
representing the image and sound recorded over a limited 
time period, during that time period, for display by the 
television set. The IEEE 1394-1995 standard bus architec- 
ture provides multiple channels for isochronous data transfer 
between applications. A six bit channel number is broadcast 
with the data to ensure reception by the appropriate appli- 
cation. This allows multiple applications to simultaneously 
transmit isochronous data across the bus structure. Asyn- 
chronous transfers are traditional data transfer operations 
which take place as soon as possible and transfer an amount 
of data from a source to a destination. 

The IEEE 1394-1995 standard provides a high-speed 
serial bus for interconnecting digital devices thereby pro- 
viding a universal I/O connection. The IEEE 1394-1995 
standard defines a digital interface for the applications 
thereby eliminating the need for an application to convert 
digital data to analog data before it is transmitted across the 
bus. Correspondingly, a receiving application will receive 
digital data from the bus, not analog data, and will therefore 
not be required to convert analog data to digital data. The 
cable required by the IEEE 1394-1995 standard is very thin 
in size compared to other bulkier cables used to connect such 
devices. Devices can be added and removed from an IEEE 
1394-1995 bus while the bus is active. If a device is so added 
or removed the bus will then automatically reconfigure itself 
for transmitting data between the then existing nodes. A 
node is considered a logical entity with a unique address on 
the bus structure. Each node provides an identification 
ROM, a standardized set of control registers and its own 
address space. 

Media devices are being equipped with network interfaces 
allowing them to become part of a network such as the IEEE 
1394-1995 serial bus network. In a home audio/video net- 
work incorporating such autonomous media devices it is 
possible that one or more such devices will be coupled 
together in a network with a personal computer, settop box 
or other device including a microprocessor. Currently, there 
is a lack of available interfaces and control applications 
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which will efficiently manage the interaction and operation 
of the autonomous devices within such a network configu- 
ration. What is needed is an interface which allows a 
controlling device within a network configuration to effi- 

5 ciently control communications between the devices and the 
operation of the devices within the network. What is further 
needed is an interface which allows a controlling device 
within a network configuration to maximize the availability 
of devices within a network for completion of tasks and 

10 operations. 

SUMMARY OF THE INVENTION 

A media manager provides data flow management and 
other services for client applications on devices coupled 

15 together within a network. Preferably, these devices are 
coupled together within an IEEE 1394-1995 serial bus 
network. A device control module is generated for each 
available device for providing an abstraction for all of the 
capabilities and requirements of the device including the 

20 appropriate control protocol, physical connections and con- 
nection capabilities for the device. The media manager also 
manages the flow and format of data transfers between the 
devices on the network. Through an interface, a user 
accesses the media manager and enters functions which are 

25 to be completed using the devices coupled together on the 
network. If the appropriate devices are available, the media 
manager controls and manages the completion of the 
requested task. If the appropriate devices are not available, 
but the required sub devices are available in multiple 

30 devices, the media manager forms a virtual device from 
subdevices in multiple devices in order to complete the 
requested task. Once the appropriate devices and subdevices 
are assigned to a task, the media manager determines if the 
data to be transmitted needs to be converted from one format 

35 into another format. If necessary, the media manager will 
also control the format conversion during the data transfer 
operation. The media manager also provides network enu- 
meration and registry searching capabilities for client appli- 
cations to find available services, physical devices and 

40 virtual devices. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 illustrates an IEEE 1394-1995 serial bus network 
45 including a video camera, a video cassette recorder, a 
computer, a television and settop box. 

FIG. 2 illustrates a block diagram of a hardware system 
resident in each device implementing the media manager of 
the present invention. 
50 FIG. 3 illustrates a block diagram of the architecture of 
the media manager platform of the present invention. 

FIG. 4 illustrates a detailed block diagram of the archi- 
tecture of the media manager platform of the present inven- 
tion. 

FIG. 5 illustrates a flow diagram of the steps involved in 
setting up and data transfer between two devices using the 
media manager of the present invention. 

FIG. 6 illustrates a flow diagram followed by a client 
60 application during startup. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENT 

The media manager of the present invention provides data 
65 flow management and other services for physical devices 
within a network. A physical device is a product sold as a 
separate component by a vendor. Examples of physical 
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devices include televisions, video cassette recorders, per- 
sonal computers, video cameras, CD-Rom players and the 
like. Many other examples are also well known and com- 
mercially available. Each physical device includes a number 
of subdevices. For example, a typical commercially avail- 5 
able video camera includes multiple subdevices, implement- 
ing different functionalities, such as the camera and the 
video player. 

Preferably, these physical devices are coupled together 
within an IEEE 1394-1995 serial bus network. A device ™ 
control module (DCM) is generated for each available 
device and subdevice. Each DCM provides an abstraction 
for all of the capabilities and requirements of each physical 
device, including the appropriate control protocol, physical 
connections and connection capabilities for the device. The 15 
media manager also manages the flow and format of data 
transfer operations between the physical devices on the 
network, including converting the data into a different 
format during the data transfer operation. 

20 

Through an interface, a user accesses the media manager 
and enters functions and tasks which are to be completed 
using the physical devices within the network. If the appro- 
priate physical devices are available and are not otherwise 
being used, the media manager controls and manages the 
completion of the requested task. If the appropriate physical 25 
devices are not available, the media manager attempts to 
create a virtual device from available subdevices or com- 
ponents within devices in order to complete the requested 
task. Once the appropriate physical devices and/or subde- ^ 
vices are assigned to a task, the media manager determines 
if the data to be transmitted needs to be converted from the 
format of the source device to the format of the receiving 
device. If a conversion is necessary, the media manager also 
controls that operation while controlling the data transfer ^ 
operation. 

FIG. 1 illustrates an exemplary system including a video 
camera 10, a video cassette recorder 12, a computer 14, a 
settop box 13 and a television 11 connected together by the 
IEEE 1394-1995 cables 15, 16 and 18. The IEEE 1394-1995 4Q 
cable 16 couples the video camera 10 to the video cassette 
recorder 12, allowing the video camera 10 to send data to the 
video cassette recorder 12 for recording. The IEEE 1394- 
1995 cable 18 couples the video cassette recorder 12 to the 
computer 14, allowing the video cassette recorder 12 to send 45 
data to the computer 14 for display. The IEEE 1394-1995 
cable 15 couples the settop box 13 to the computer 14. The 
settop box 13 is also coupled to the television 11 by the cable 
17. 

This configuration illustrated in FIG. 1 is exemplary only. 50 
It should be apparent that an audio/video network could 
include many different combinations of physical compo- 
nents. The physical devices within such an IEEE 1394-1995 
network are autonomous devices, meaning that in an IEEE 
1394-1995 network, as the one illustrated in FIG. 1, in which 5S 
a computer is one of the devices, there is not a true 
"master-slave" relationship between the computer and the 
other devices. In many IEEE 1394-1995 network 
configurations, a computer may not even be present. Even in 
such configurations, the devices within the network are fully 60 
capable of interacting with each other on a peer basis. 

A block diagram of a hardware system resident in the 
managing device for implementing the media manager of 
the present invention is illustrated in FIG. 2. In the hardware 
system illustrated in FIG. 2, a printed circuit board 20 is 65 
coupled to a user interface 30. The printed circuit board 20 
includes a central processing unit (CPU) 22 coupled to 
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system memory 24 and to an I/O bus interface 26 by the 
system bus 28. The use of the term 'CPU' is not intended to 
imply that such a system must be a general purpose com- 
puting circuit. Rather, this circuit could be implemented with 
a general purpose controller or special purpose circuit. The 
user interface 30 is also coupled to the system bus 28. The 
user interface 30 is subsystem specific, but preferably 
includes at least an infrared remote control device and a 
display. Alternatively, the user interface 30 also includes 
other I/O devices for communicating with a user of the 
subsystem. 

In the preferred embodiment of the present invention, the 
media manager is included within a device such as a 
television or a computer with display, in order to facilitate 
smooth interaction with the user However, it should be 
apparent that the media manager of the present invention can 
also be implemented on any other capable device which 
includes the components necessary for providing an inter- 
face to the user. In order to implement the media manager of 
the present invention, each component in which it is imple- 
mented will include a hardware system such as the system 
illustrated in FIG. 2. The CPU 22 within such a device is 
used to execute the application program instructions. The 
media manager of the present invention is then used to 
manage communications and operations within the network. 
The user accesses the media manager through the interface 
provided at the controlling device. Through this interface the 
user can monitor the operation and status of the network and 
the devices within the network. The user can also control the 
devices and request tasks to be completed through this 
interface. An example of these tasks include playing a 
recorded tape on the VCR 12 and displaying the output from 
the VCR 12 on the television 11. The media manager of the 
present invention also manages data transfer operations and 
tasks requested at the individual devices. 

A block diagram of the architecture of the media manager 
platform of the present invention is illustrated in FIG. 3. This 
architecture is divided into a so-called upper portion 32 and 
a lower portion 34. The lower portion 34 preferably includes 
the IEEE 1394-1995 bus interface and functionality support 
across the most common commercial operating systems 
currently available. The upper portion 32 includes compo- 
nents which bring together the underlying IEEE 1394-1995 
bus support and add in a number of features and enhance- 
ments which are provided to the client applications and 
therefore to the user. The upper portion 32 includes the block 
46, which provides specific design and implementation for 
higher level IEEE 1394-1995 bus support, and the block 48, 
which includes and provides interfaces to the various client 
applications. The lower portion 34 includes the blocks 40, 42 
and 44 which provide support for the most common oper- 
ating systems, including Windows 95®, Macintosh® and 
Aperios™ operating systems, respectively. Support for any 
general operating system, such as OS9, is also provided. The 
lower portion 34 also includes the block 38, which provides 
the common layer of IEEE 1394-1995 support, and the 
blocks 36 which provide the actual physical IEEE 1394- 
1995 bus interfaces to other devices coupled to the control- 
ling device. 

The media manager platform provides an open and flex- 
ible architecture in order to efficiently integrate personal 
computers and other autonomous devices into a network 
configuration and effectively manage the necessary data 
transfer operations between those devices. The lower por- 
tion 34 of the architecture has been designed to support the 
underlying technology at the lowest levels, which allows the 
higher levels to support more general modules and func- 
tional descriptions. 
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A more detailed block diagram of the architecture of the didates are found during this search, the service registry 59 

media manager platform of the present invention is illus- will provide a list reference to the client application 48. The 

trated in FIG. 4. The multimedia or user-level application 48 client application can then examine each of the candidate 

sits at the top of the architecture and makes use of the items in the list, to determine the items of interest, 

services provided by the media manager. The multimedia 5 A client application 48 may have multiple outstanding 

application 48 is an application or other client of the media search ^ eacfa enti me results of a different 

manager platform of the present invention. The architecture gearch criteria Wfaen ^ ^ lication ^ needs to 

components within the media manager manage the protocol date a ^ in ^ tQ an eyent sucfa ag a feus 

specifics and export a simpler programming interface up to feset m whkh may be availablc> the 

the application 48. Issues such as timing, buffer 10 application 48 passes the Ust refer ence back to the service 

management, bus management and communication protocol ^ 59 whc[] making a scarch call ^ allows thc 

are hidden behmd these simple functional interfaces. The sefvice . 59 to date ^ exisU ^ objectj father 

application 48 also has access to the lower layers of the ^ dis ^ of it and rcaUocating a new one. 

architecture and will of course be able to communicate . , * ™ ji ul l hj 

• • 4l «.i i % j * * * 1 /tjAT \ „_j *u A The service modules 60 are modules which can be called 

directly with the hardware adaptation layer (HAL) and the 1S . . . _ „ 

. 4 ' . -o , , * „ •„ to perform some set of services. The service modules 60 

host operating system 58. The host operating system is * . ■ 1 j 

. j , ,% ,? , . ,t , i u *u- perform a variety of services for client applications, mclud- 

coupled to the other devices within the network, such as the f . J , f ^ j' 

iL ^™ « a i ,i ** u ii r- -ii * me such services as data format, transport and control 

camera 10, the VCR 12 and the settop box 13. For Ulustra- & ^ ' ^ 

tion purposes, in this configuration the media manager of the pr °° C ° ° U ' mA . , c , «. . 

present invenUon is implemented on the computer system 14 2Q The DCM manager 54 is responsible for handling the 

of FIG 1 group of DCMs 56 on its local node or for the devices within 

™ \. • * r u- . en „ ™™ firw the controlling device's network. These responsibilities 

The application interface object 50 serves as a proxy tor f rJ - • j j- 

*i_ t * v ** aq -tu- n «™.To„,»™« mclude the tasks of discovering, instantiating and disposing 

the chent application 48 within the media manager environ- 4 &> . t . - 

, » i • * ■ - ,ia~a tn of all possible DCM candidates that are available to a given 

ment. An applications programming interface is provided to ™"rw * ♦ 

ii *u v * r o /iH * rt t™co »k„ k 4 L system. In addition, the DCM manager 54 communicates 

allow the client applications 48 to access the basic services 2 s ... A . * j p 

of the media manager. Access to more detailed or specific ^ f e / DC ™ "pagers on remote nodes, ,f any to 

functionality provided by certain programming interfaces is for network-wide dev.ee and subdevu* resource 

also provided through the application interface object 50 location and management. 

which provides the application 48 access to the local mes- The DCM manager 54 works with the underlying oper- 

senger 52 30 itin 8 system services to get a raw list of available device 

The local messenger 52 is one component of the messag- nod f. h * ndles - ™ e DCM ™ na S e 7 5 * Prides an 
ing system integrated into the media manager. Preferably, apphcation programming interface for the client application 
this messaging system is the AV Messenger system. The 4 « to d * cover whal subdevices represen^d by DCMs 56, or 
local messenger 52 is the central hub of communications other services are available within the devices on the net- 
between all objects on a given node, when those objects 35 work. A DCM 56 represent a device or subdevice av^lable 
exist in separate execution spaces. Essentially, the local for allocation by the DCM manager 54. A DCM 5 can 
messenger 52 is the inter-application communication model represent a physical device or a virtual device formed of 
which £ provided by the host operating system 58. The local **P«ts from * fferC ? J^^^ °2-T!?f £ 
messenger 52 is the bottleneck through which all messages services are represented by virtual DCMs 56 which will be 
between software modules pass. To achieve scriptability, the 40 f^ ed below ' The available DCMs will be dynamic 
local messenger 52 logs all messages as they pass through, fP^S on .the available physical devices on the IEEE 
keeping an internal database of all messages and their 1394-iyy5 senal bus. 

relevant data including address of destination, parameters, For each node, the DCM manager 54 does enough work 

address of response and optionally, a time stamp for time- to determine that it should create a DCM 56. This is done for 

based scripting 45 a11 media-related devices which will be managed under the 

Hie service registry 59 includes a reference to all addres- ™breU of the media manager of the present invention. For 

sable entities within the media manager 71. This registry etch P^™^^^^ man ^ er 54 crea ^ s , a 

includes a reference for each device control module (DCM) fc™enc DCM 56. Each DCM 56 then has the responsibly 

56, the DCM Manager 54, the data flow manager 64, the 10 make llself more device-specific, as will be described 

transaction manager 66, the data format manager 68, the bus 50 bd° w ' 

manager 70 and the graphics manager 72. The service Device-specific DCMs provided from manufacturers can 

registry 59 also contains any number of service modules 60, also be added into the DCMs 56. Device-specific DCMs can 

as will be described below. The service registry 59 also come from a variety of sources including an embedded 

contains a service registry database including references for read-only memory (ROM) within the device or some other 

all of the objects that are local to its node and at specific 55 storage mechanism such as the header of a disc or tape. The 

times references to remote objects as well. Each entry in the device-specific DCM may also be downloaded from an 

database refers to an addressable module and includes internet site or via a direct modem connection, if such 

attached attributes, some of which are common to all entries capabilities are accessible to the media manager, or supplied 

and others which are specific to a type of module. Common from a disk or other storage medium. These alternatives are 

attributes include such things as the module name and the 60 discussed in detail in the U.S. patent application Ser. No. 

local ID. Module-specific attributes will vary by the type of 06/092703, filed on Jul. 4, 1998 (pending) and entitled "A 

module. Once the entry exists in the service registry METHOD AND APPARATUS FOR INCLUDING SELF- 

database, any number of attributes can be added to an entry. DESCRIBING INFORMATION WITHIN DEVICES/' 

When a client application searches the database, the appli- which is hereby incorporated by reference, 

cation specifies a set of attributes to match and the service 65 The DCM manager 54 is responsible for adding and 

registry 59 searches the database, finding and returning all disposing DCMs 56 at the appropriate times, and notifying 

entries which match the specified criteria. If multiple can- clients that DCMs 56 have been added or removed. The 



03/22/2004, EAST Version: 1.4.1 



US 6,233, 

7 

DCM manager 54 is also responsible for coordinating com- 
plex services among multiple DCMs 56. These complex 
services, such as command queuing of complex operations, 
require the DCM manager 54 to coordinate with multiple 
DCMs 56 to carry out these operations. S 

The DCMs 56 each provide a device modeling and 
control protocol abstraction service by exporting a standard- 
ized interface for device control up to the client application 
48. The programming interface for device control provided 
by the DCMs 56 is divided into common A/V control and 10 
device -specific A/V control. The common A/V control com- 
mands are common to virtually all devices having audio- 
visual capabilities. The basic transport control functionality 
such as Play, Stop, Fast Forward and Rewind commands are 
included here. The device -specific A/V control commands 15 
include features common to a given category of A/V 
devices, such as the Record command for devices with 
recording capability, and features that are specific to a 
certain model or group of devices. The information for 
device-specific functionality can either be built into a 20 
device-specific DCM which is embedded in the device itself, 
using the self -describing data structures mentioned 
previously, or it can be downloaded as a software upgrade 
from the internet. 

The media manager of the present invention employs 25 
protocol abstraction which means that the programming 
interface between the modules and the application is the 
same, regardless of the kind of device and the controlling 
protocol being used. Accordingly, the application will use 
the same source code and message to cause an IEEE 
1394-1995 VCR to record as it would use to cause a Video 
System Control Architecture (VISCA) VCR to record. This 
is true for the common A/V control commands and the 
category -specific control commands; features that are truly ^ 
specific to a particular device will have a unique program- 
ming interface. 

The DCM 56 is the mechanism by which self -describing 
data from a device is downloaded and presented to the user. 
This requires the DCM 56 to analyze the self-describing 4Q 
information, by downloading and integrating modules and 
managing the presentation of this information to the user 
through a host application. This allows a user to configure 
and control both the well-known and device-specific func- 
tionality of devices on the network through the media 45 
manager interface. The preferred presentation of user inter- 
face data and access to custom functions of the device is 
described in the U.S. Provisional Patent Application Ser. No. 
60/054,199, filed on Jul. 30, 1997 and entitled "METHOD 
FOR DESCRIBING THE HUMAN INTERFACE FEA- 5Q 
TURES AND FUNCTIONALITY OF AV/C-BASED 
DEVICES " which is hereby incorporated by reference. 

Together, the DCM manager 54 and the DCMs 56 per- 
form command queuing of AV commands to be executed, 
allowing the DCM 56 to deal with all device peculiarities, S5 
such as the need to perform a pre-roll to account for 
mechanical latency of a device. The DCM manager 54 and 
the DCMs 56 in coordination with other parts of the media 
manager also provide the ability to specify device control 
actions that are taken at specific times and as the result of 60 
certain conditions. 

The DCMs 56 make up a large part of the overall 
architecture of the media manager of the present invention. 
The DCM 56 provides an abstraction for all of the various 
pieces of technology that make up an audio-visual device, 65 
such as the control protocol, physical connections and 
connection capabilities. A DCM 56 can also be created 
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which does not represent a physical device, but represents a 
virtual device comprising a collection of functions or ser- 
vices that carry out a particular AV operation. 

Physical devices and subde vices are individually acces- 
sible pieces of hardware. The media manager of the present 
invention uses accessible subdevices to support virtual 
devices to add enhanced capability to a network of devices. 
The virtual devices are logical entities which are combined 
from pieces of a variety of available components. Preferably, 
the virtual devices are created automatically when necessary 
to complete a requested task. Alternatively, the virtual 
devices are created dynamically by requesting the service 
from the DCM manager 54. 

An AV action is a pre-defined action or activity such as 
"watch television" or "record a movie/* or any set of 
user-defined actions involving the manipulation of devices 
by using the DCMs 56. The actions can be recorded for later 
re-use by a user. An AV action applications programming 
interface is a way of modeling common actions that are 
performed with devices in an AV network, such as viewing 
a recorded show, viewing a broadcast show, duplicating a 
tape and listening to a compact disk. For example, if a VCR 
is located in an upstairs bedroom within a user's house and 
is currently receiving a broadcast through the tuner and 
displaying it on a television in the bedroom, the transport 
mechanism within the VCR is not being used. If the user 
then desires to view a recorded show on the television 
downstairs, the media manager of the present invention will 
allow the user to place the video tape in the transport of the 
VCR in the bedroom and watch the recorded show from the 
tape on the downstairs television. The data representing the 
recorded show is transmitted from the upstairs VCR over the 
IEEE 1394-1995 serial bus network to the downstairs tele- 
vision. This data transfer operation is controlled by the 
media manager in the controlling device. Similar functions 
and virtual devices are achieved with tuners, demuxers, 
transports, amplifiers, processors and other components and 
subdevices. Accordingly, the user can maximize the func- 
tionality and capability of the devices within the network 
using the media manager to control their operation. 

The DCM manager 54 keeps track not only of what 
physical devices and subdevices are being used, but also 
what virtual devices can be created from components and 
subcomponents that are currently available. The DCM man- 
ager 54 does this for all of its locally managed devices and 
for software services available on the host platform on 
which it is executing. The DCM manager 54 also provides 
the programming interfaces for a client application 48 to 
inquire about the virtual devices that can be created based on 
the resources available on the network, as well as what AV 
actions can be currently performed. The DCM manager 54 
also ensures that virtual devices get added to the service 
registry 59 at the appropriate times. 

The applications programming interface provided for the 
DCMs 56 is designed to allow the client applications 48 to 
discover what features and capabilities are available within 
the devices in the network and then work with those devices 
as necessary. This programming interface includes device 
control, device management, connection management and 
management of the self-describing device implementation. 
Each of the DCMs 56 have the responsibility to convert from 
a generic DCM to a device or protocol specific DCM by 
determining the type of device it is managing. This requires 
that the DCM examine the self-describing device data from 
the device, if any is present, and analyze any other infor- 
mation that may be available. The DCMs 56 also have the 
responsibility to provide access to the self -describing device 
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information data for the device being managed, including 
the device image, a product name string and functional 
descriptors to other devices and components. The DCM 56 
is further responsible for providing a consistent interface for 
device control, including the complex services such as 5 
command queuing. Carrying out these commands requires 
coordination with the host operating system 58 for device 
control protocol usage, including packaging, sending, pro- 
cessing protocol-specific commands and responses via the 
protocol driver and other operating system provided support 10 
mechanisms. 

Each DCM 56 also monitors the device it is controlling 
and provides extended notification support to the necessary 
components and applications. All normal events generated 
by the device go through the DCM 56 for the appropriate 15 
device, to the event manager 62 and to all interested client 
applications 48. In addition to supporting the AV/C device 
notification events, many situations may not be supported 
explicitly in either the AV/C protocol, in a given device or 
other control protocol. Depending on the capabilities of the 20 
device and its control and communications protocols, it is 
possible to provide extended support for such events which 
do not trigger actual event messages. The DCM 56 watches 
the device for this kind of activity and posts an event to the 
event manager 62. 25 

Each DCM 56 is also responsible for managing them- 
selves in terms of the outside entities which are making use 
of the data from the device under their control and the 
entities that are controlling them. This includes support for ^ 
resource sharing and resource queuing. Resource queuing 
allows an entity to reserve a busy DCM for its use, as soon 
as the DCM 56 is available. As soon as the DCM 56 is 
available, it will then notify the entity. 

The DCMs 56 also preferably maintain a presence during 35 
environmental changes allowing the DCM and clients to 
support both on-line and off-line states. This allows the 
DCMs 56 to quickly re-establish the services of a device 
once it comes on-line again. 

Within the media manager of the present invention, the 40 
DCMs 56 are responsible for controlling the available 
devices and subdevtces. The DCMs 56 provide access to the - 
capabilities of the device, both general and device-specific. 
In an alternate embodiment of the present invention, each 
device, as part of the self-describing data, has an embedded 45 
DCM, ensuring that the software is always available regard- 
less of where the device is taken. In a further alternate 
embodiment, the DCM for a specific device is obtained from 
the device manufacturer or a third party over the internet or 
provided on a media device, such as a floppy disk. In each 50 
of the above embodiments, the DCM 56, once downloaded 
can be stored in a variety of locations. Preferably, the DCM 
56 is stored on the device it controls. However, the DCM 56 
can also be stored in any appropriate location. In an alternate 
embodiment of the present invention, the DCM 56 is written 55 
in common byte or script code format, such as Java or Java 
Script, supported by the host platform. The DCM 56 is then 
uploaded to the host device and executed there. 

The event manager 62 broadcasts all event notifications 
within the network to all interested parties. The event 60 
manager 62 acts as a central location for all modules within 
its node to register for notification when events occur in that 
node. The event manager 62 maintains an event notification 
list data structure which is a list of the defined event types 
and the destination identifiers of all devices which have 65 
registered for notification of each type of event. The devices 
each register with the event manager 62 for each event type 
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that is of interest to them, providing their client identifier and 
a token value to be passed back to them when the event 
message is broadcast. An event is an actual occurrence of 
some action and a message from a device which is addressed 
to multiple destinations. 

The event manager 62 does not usually generate events, 
but accepts and broadcasts events posted by other compo- 
nents with the media manager. When broadcasting events to 
client applications 48 in remote nodes, the event manager 62 
makes use of the broadcast manager 74. The event manager 
62 handles the interaction with the user and informs the 
appropriate devices accordingly. The event manager 62 
informs the DCMs 56 of what user input is occurring 
through the interface at the control software level, so that the 
DCMs 56 can handle their physical devices appropriately. A 
DCM 56 controlling its device from a remote location will 
need to receive messages indicating what the user is doing 
and will need to send appropriate messages to its device. The 
event manager 62 supports the execution of remote DCMs 
56 by means of the messaging system and well-defined 
event messages. The well-defined event messages include 
device administration, such as a new_device message gen- 
erated when a device is added to the network, and user 
interaction. The user interaction messages support the pre- 
ferred graphical user interface model as described in the 
U.S. Provisional Patent Application Ser. No. 60/054,199, 
filed on Jul. 30, 1997 and entitled "METHOD FOR 
DESCRIBING THE HUMAN INTERFACE FEATURES 
AND FUNCTIONALITY OF AV/C-BASED DEVICES," 
which is hereby incorporated by reference. In addition to 
well-defined event messages, any two DCMs or software 
modules can also define custom or private messages. 

The graphics manager 72 manages the embedding of 
remote device controls into a controlling application and 
supports the remote presentation of self-describing data 
information by the DCMs 56. The graphics manager 72 
provides a programming interface that allows the DCMs 56 
to arbitrate for screen space and to work within a shared 
graphics environment. This allows the specific capabilities 
of a device to be presented to and accessed by the user 
through the interface of the controlling software. 

The data format manager 68 manages the format of the 
data flowing between devices. This includes the ability to 
plug into the resident media manager for data format con- 
version as part of the buffer management and data format 
process. Most of the data format conversions are done 
transparently on behalf of the client application, based on 
knowledge of the source and destination of the data. Other 
data transformations require the client application 48 to set 
up a format conversion process. Preferably, the format 
conversion is performed in-line while the data is being 
transmitted. Alternatively, the format conversion is per- 
formed as either a pre or post processing task to transmission 
of the data. The data format conversion services available on 
a given platform are stored in the service registry 59. In 
addition to using the registry to find services, the data format 
manager 68 is responsible for instantiating the service 
modules and registering them with the service registry 59. 

The data flow manager 64 works with the bus manager 70 
to provide services to assist with routing data from source to 
destination, which may include many nodes in between. In 
the event that the source and destination device involve 
different data types, or are separated by a barrier, the data 
flow manager 64 will work with the data format manager 68 
and the service registry 59 to handle automatic or requested 
data translation services as well. During the transfer of 
isochronous data, the data flow manager 64 provides buffer 
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allocation and management services. Buffer management present invention. The bus manager 70 notifies the client 

includes the provision for a consistent notification mecha- applications 48 when bus reset activity occurs by sending 

nism to inform the client application when data is available out bus reset notifications through the event manager 62 and 

for processing. While isochronous data is flowing into the providing complete information about how the environment 

client application 48, various memory buffers are filled with 5 has changed. The client applications receiving this informa- 

the data. The data flow manager 64 informs the client tion are provided with information about the devices which 

application 48 when each buffer is filled so that it can handle may have suddenly disappeared and the devices which have 

the data acquisition process from the buffer. In addition, suddenly become available after the bus reset, 

buffer management is simplified for client applications by The bus manager 70 also provides topology maps, speed 

having the appropriate service modules partition memory in 10 ma P s fl nd other environment descriptions to client applica- 

a manner that is optimized for the data being captured. This tions 48. Information from the topology map is used to build 

includes separating the allocated memory into scan line or a user interface that helps the user understand the connection 

frame-sized segments for a stream of video data or the of the devices and how certain features may be used. This 

optimum segment sizes for raw audio and MIDI data. information is also used to provide automatic data routing as 

A flow diagram of the steps involved in setting up a data 15 described above in relation to the data flow manager 64. The 

transfer between two devices using the media manager of speed map is used to analyze the current connection scheme 

the present invention is illustrated in FIG, 5. The method and to give the user helpful suggestions for improving the 

starts at the block 100. When a client application 48 desires performance of devices on the network by rearranging the 

to establish a connection between two devices for a transfer way that devices are connected. The bus manager 70 also 

of data the application calls the 20 provides atomic-level date communications services for two 

EstablishExternalConnectionO method of one of the two nodes or software modules within the nodes, to send bytes 

DCMs 56 that represent the two devices and passes the to each other in a preferred format or protocol. This protocol 

modulelD value of the other device's DCM 56 as a param- * built on top of those atomic communications functions, 

eter. (Block 102) The DCM 56 that was called then calls the After a bus reset or change notification of the bus, the bus 

data flow manager 64 to assist with making the connection 25 manager 70 assigns new ID values to all devices which have 

and passes both the source and destination DCM modulelDs just appeared and determines what devices have disap- 

as parameters. (Block 104) Hie data flow manager 64 then peared. The bus manager 70 then invokes the DCM manager 

analyzes the source and destination IDs to determine that 54 to create new DCMs 56 for the devices which have just 

they are in different nodes. (Block 106) The data flow appeared and posts a bus change notification to the event 

manager 64 next obtains the topology map of the network 30 manager 62, which will notify all registered clients about the 

from the bus manager 7 of the source node. (Block 108) The bus reset. This notification provides enough information for 

data flow manager 64 then analyzes the topology map to find the client applications 48 to determine what devices have 

the destination node and determine if it is on the topology changed on the bus. 

map. (Block 110) If the destination node is on the topology The transport adaptation modules 78 take care of pack- 
map, then the data flow manager 64 jumps to the Block 118 35 aging message data before it is passed on to the HAL for 
to determine the best route for the data transfer. If the actual transmission to the destination device. The HAL is at 
destination node is not on the topology map, then the data the lowest layer of the media manager of the present 
flow manager 64 obtains the destination DCM from the invention. This layer provides a common programming 
service registry 59 in order to determine the transmission interface upward to clients such as the DCMs 56 and any 
protocol for that node. (Block 112) The data flow manager 40 other entities that need to communicate with it. The transport 
64 then finds the appropriate transmission protocol service adaptation modules 78 use the atomic messaging functions 
module and sets up the appropriate conversion process. of the bus manager 70, as described above. 
(Block 114) It is then determined if multiple transports need As described above, the DCMs 56 provide a protocol 
to be bridged. (Block 116) If multiple transports do need to abstraction service, by exporting a standardized interface for 
be bridged then the data flow manager 64 jumps back to the 45 device control up to the multimedia application 48. The 
Block 114 and obtains another transport conversion module. programming interface provided by these components is 
Otherwise, the data flow manager 64 then analyzes the divided into a common audio/video control level and a 
connection paths to determine the best route for the data device -specific control level. The common audio/video con- 
flow. (Block 118) The data flow manager 64 then analyzes trol level provides an interface for common commands, 
the input data formats for the source and the destination 50 including the basic transport control functionality, such as 
nodes in order to determine if a conversion is necessary. Play, Stop, Fast-Forward and Rewind commands. The 
(Block 120) If a conversion is necessary, the data flow device-specific control level provides an interface for 
manager 64 obtains the appropriate format converter from device-specific commands, including features common to a 
the service registry 59, based on the input and output format given category of devices, such as Record for devices with 
and sets up the conversion process. (Block 122) Otherwise, 55 recording capability, and features which are specific to a 
the data flow route is complete and the data transfer between certain device or group of devices. The protocol abstraction 
the two devices can begin. (Block 124) service provided by the DCMs 56 ensures that the program- 
The bus manager 70 abstracts the underlying device ming interface between the modules and the application 48 
interconnection mechanism, providing a common set of is always the same, regardless of the kind of device and the 
programming interfaces to describe the capabilities of the 60 controlling protocol being used. This feature allows a great 
bus architecture. In the preferred embodiment of the present degree of flexibility for the application and the user. The 
invention, the devices are connected by an IEEE 1394-1995 DCMs 56 also provide a user input event abstraction model, 
serial bus. For the IEEE 1394-1995 serial bus network, the so that client applications can display graphical user inter- 
bus manager 70 resides on the top of the IEEE 1394-1995 face elements and send standard user event messages to the 
HAL layer that is provided by the host operating system 58 . 65 DCM 56 as the user interacts with the graphical user 
The bus manager 70 then helps to generalize the bus interface elements, as described in U.S. Provisional Patent 
management activities up to the media manager of the Application Ser. No. 60/054,199, referred to above. 
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The media manager of the present invention provides data 
flow management and other services. The media manager 
acts as an extension of the hosting operation system 58 and 
provides a variety of services to the other components of the 
media manager platform as well as to the client application 5 
48. The media manager manages and organizes the DCMs 
56. The media manager discovers and initializes the DCMs 
56 which are appropriate for the applications present, while 
disposing of the unnecessary DCMs 56. The media manager 
follows a specific sequence each time the system is booted, 10 
or any time the system could possibly change, sucb as when 
the IEEE 1394-1995 bus is reset. The media manager also 
provides a wrapper around the particular dynamically linked 
library solution that is used on the host operating system 58. 
This allows the best dynamically linked library to be used to is 
implement modules on a given operating system, while still 
maintaining a consistent interface to outside applications. 

The media manager is also responsible for managing the 
flow and format of data transfer operations between the 
devices on the network. When managing the flow of data, 20 
the media manager will allocate and manage the appropriate 
buffers in a fashion independent of the operating system 
being used. 

The media manager also provides high-level protocol 
management of the IEEE 1394-1995 bus environment. In 25 
order to fully support dynamic device actions such as hot 
plugging up to the user level, the applications and devices 
need to be aware of changes to the IEEE 1394-1995 bus 
environment. The media manager through the bus manager 
70 and the event manager 62 is responsible for informing the 30 
applications and devices that bus reset activity has occurred 
on the IEEE 1394-1995 bus, by sending out bus reset 
notifications and providing complete information about how 
the environment has changed. The media manager also 
provides topology maps and other environment descriptions 35 
to the applications and devices also through the bus manager 
70. The topology map illustrates the connections between 
devices within the IEEE 1394-1995 network. Information 
derived from the topology map is used to build a human 
interface which helps the user understand how the devices 40 
are connected and how certain features may be used. 

The application service modules 60 provide a level of 
services between the host operating system 58 and the 
application 48 in order to provide basic functionality for the 45 
application 48 independent of the specific operating system 
being used. This functionality includes providing memory 
allocation and disposal routines which are more robust than 
the basic functions available in most operating systems and 
providing device configuration and control modules which 5Q 
are self-contained, stand-alone modules for providing all 
user interface and interaction management when invoked. 

The transport adaptation modules 78 provide a common 
programming interface to the device control modules 50 and 
to the application 48, taking care of bringing the protocol 55 
capabilities up through the host operating system 58. The 
internal design and implementation of the system level 
interface block 50 takes advantage of the specific host 
operating system architecture being used in order to realize 
the IEEE 1394-1995 functions available to the application 60 
48. 

The media manager platform of the present invention 
includes the DCMs 56, the application service modules 60 
and the system level interface for IEEE 1394-1995 bus 
protocol provided by the transport adaptation modules 78. 65 
During normal operation, the application 48 will communi- 
cate with all of these components. When communicating 
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with the DCMs 56, the application 48 will use a single 
programming interface. When communicating with the 
application service modules 60, the application will also use 
a single programming interface. 

A client application 48, as described above and illustrated 
in FIGS. 3 and 4, is an entity which resides above all the 
other components in terms of the architecture of the media 
manager platform of the present invention. For the comple- 
tion of a majority of its required tasks, the application 48 will 
communicate with the DCMs 56 and the application service 
modules 60 which are present via the local messenger. For 
the times when it is necessary, the application 48 has access 
to the lower levels of the architecture through the host 
operating system 58. 

Upon startup of the client application 48, the client 
application 48 must initialize and register with the media 
manager. The client application 48 initializes the media 
manager in order to make sure that the media manager is up 
and running and ready to serve the application 48. The client 
application 48 registers with the media manager in order to 
give the media manager all of the necessary information for 
interaction with the application 48 and to register itself with 
the messaging system. When starting up, generally an appli- 
cation 48 must make sure that the host operating system has 
been initialized, that a minimum level of services are avail- 
able and that it has the necessary amount of memory 
available to run. These steps are performed for the applica- 
tion by the media manager after the application 48 initializes 
the media manager. 

When starting up, a client application 48 follows the steps 
illustrated in the flow chart of FIG. 6. The application 48 
starts up at the step 140. After starting up, the application 48 
initializes the media manager. In the preferred embodiment 
of the present invention the application initializes the media 
manager by making the following call: 

err=SMM_Jnitialize 
When initialized, the media manager will allocate the nec- 
essary memory and system services to support the applica- 
tion 48. 

After initialization of the media manager is complete, the 
application 48 then registers with the media manager at the 
step 144. This step of registering allows the application 48 
to provide the media manager with specific information that 
the media manager will need in order to properly support the 
application 48. For example, the application 48 must provide 
the address of a callback routine for notification of signifi- 
cant events related to the environment, including IEEE 
1394-1995 bus resets, asynchronous transaction completion 
and triggers when memory buffers have been filled with a 
specified amount of isochronous data. The step of registering 
is completed by the following instruction: 

SonyErrorResultType SMM_Register Client 
(SMMClientldentifierTVpe* the ClientID, 

SMMBusEventNotificationUPP 
clie ntBusEventNotificationCallback, void* 

clientBusEventCallb ackD a ta); 
The parameter thedientlD is a unique identifier created by 
the media manager for the application. In future communi- 
cation with the media manager, the application 48 will be 
required to pass this identifier back in, such as when it is 
closing down and unregistering with the media manager. 
The parameter clientBusEventNotificationCallback is an 
appropriately formatted reference to the callback function 
that the application 48 will implement. The application 48 is 
not required to implement such a callback function if the 
application 48 does not need to know about dynamic 
changes which may occur to the network environment. If the 
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application 48 does not implement this callback function, function so that the application 48 can save this parameter 

then the application will pass a NIL value for this parameter. along with the other information passed into the callback 

The parameter clientBusEventCallbackData can be any function. This index value is useful in other calls to the 

value that the application 48 will require access to in the media manager by the application 48, when inquiring about 

callback routine. Normally, this value will be a pointer to a 5 a specific DCM 56. In addition, this index value will be used 

block of memory such that when the media manager invokes wnen notifying the application 48 that a device has disap- 

the callback function, it will pass this value back to the client pea red after it was unplugged or disconnected from the 

application 48, allowing the application 48 to then access nel work. The application 48 will store this index value for 

global storage or other appropriate data. each DCM 56 a dedicated field in its private data 

To complete the step of registering with the media 10 stnicture 

manager, the application 48 must also implement the noti- m , . , „ 

fication callback function using the following interface: ™* parameter devicelnfo of the callback function is a 

pascal void (*SMMBusEventNotifIcationProcPtr)(void P ointcr to a data structure labeled SonyAVDeviceRec, m 

*clientData which the media manager stores the DCMs 56 for retrieval 

SMMBusEventType busEventlndicator, SMMBusEven- 15 by the application 48, The format of this data structure is 

tRecPtr busEventlnfo); known to both the application 48 and the media manager. 

The parameter clientData is the clientBusEventCallback- Once a DCM 56 is stored within this data structure, the 

Data parameter that was passed in to the registration func- application 48 will then copy the appropriate information 

tion. The parameter busEventlndicator is an enumerated from me data structure to its own private data structure. The 

data type which indicates what kind of event the application 20 data structure SonyAvDeviceRec is defined in Table I below: 
is being notified of. The specified events include a bus reset, 

when a device is plugged into or unplugged from the TABLE I 

network, the completion of an asynchronous transaction and ^ ^ __ .^—^^ 

when a specified buffer is full during an isochronous transfer ^^ S "* VDwtaRec dcvicdD; //SMMDrtcdDiyprf 

of data. The parameter busEventlnfo provides a data struc- 25 u^g^a i ong busGeneration; 

hire that contains relevant information for the particular soNY_DeviceModuleRefType controlModulcRcfcrcncc; 

event unsigned long reservcdl; 

After completing the step of registering with the media s *° v £ Rec , . SmyAVDev ^Z^ SoayAvDeviaR ^ 
manager, the application 48 then will obtain the available 

DCMs 56 at the step 146. By obtaining the available DCMs 30 

56, the application 48 will know the other types of devices The parameter devicelD is the identifier of a DCM 56 and 

which are coupled within the network. This step is com- correspondingly of a device. This identifier is used by the 

posed of a series of sub-steps. An iterative callback model is application 48 whenever it wants to communicate with a 

used as the method of data transfer for transferring the data UCH 56 or when the application 48 requests services from 

to the application 48. The client application 48 first gives the 35 ^ media manager regarding a specific device, 

media manager an address of a callback taction. Hie parame ter busGeneration is a value which changes 

application 48 then enters a loop and repeateoTy reques s J ^ ^ 

information about the next module from the media manager j • • r *• u **u 

until there are no remaining DCMs. The media manager devices are added or removed, certain information about the 

prepares a data structure with the necessary information and 40 bus and the connected devices will change. Each time that 

transfers it to the application 48 via the callback function. 'he IEEE 1394-1995 bus is reset, the value of the parameter 

Once the information about each specific DCM 56 is busGeneration is updated. 

received, the application 48 then copies the information The parameter controlModuleReference is a reference to 

which it requires. This process is repeated until all of the the DCM 56 that is associated with the specified device. This 

available DCMs 56 have been received by the application 45 reference is used when the application 48 requires the media 

48 . Within an alternate embodiment of the present invention, manager to act on its behalf in transactions with the module, 

the client application queries the system registry, requesting Thc application 43 ^ next reqU cst that the media 

a handle to each of the available DCMs 56. manager generate a list of available DCMs 56 and the 

The preferred callback function which the application 48 numb er of modules within that list using the following 

must implement to obtain the available DCMs 56 is defined 50 ca u : 

as follows: SonyErrorResultType SMM_FindDeviceControlMod- 

™ DeV T lC ; In £ h 1 h° T (V a nl 'r1^; ules (SMMDeviceL^tReflVpe* theDeviceList, unsigned 

de^Sfor deV1CeIndeX ' SonyAvDeviceRecPtr ^ ^ eviceAUributes> short r niim AVDevices) 

The parameter userData of the callback function is the 55 The parameter theDeviceList includes the address where the 

means of transferring data between the media manager and list of available DCMs 56 is stored and is generated and 

the application 48. The application 48 will define its own returned by the media manager. The application will declare 

data structure, allocate the memory for one of these struc- * local variable of this type and pass the address of that 

tures and pass the address of that structure to the media variable to this function. 

manager. That address is then passed back in this callback 60 The parameter device Attributes includes a set of bitwise 

function allowing the application 48 to access that data flags which the application 48 uses to specify the types of 

structure for the purpose of copying information into it. DCMs 56 which should be returned. For example, the 

The parameter devicelndex of the callback function is the application 48 may only wish to know about the active 

index value of the loop which the application 48 enters to devices connected to the network. When certain flag values 

obtain information about the available DCMs 56. The loop 65 are specified the media manager will filter the list for only 

is bounded by the number of available DCMs 56. This the devices meeting the criteria, before the list is returned to 

parameter is passed back to the application 48 in the callback the application 48. The application 48 can specify that the 
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list include all identifiable devices, only devices that are up 
and running, only devices that are plugged in but have their 
power switch turned off or only snoozing devices. 

The parameter numAVDevices includes the number of 
DCMs 56 in the list that is returned to the application 48. 
The application 48 uses this number as the upper boundary 
of the iteration loop to obtain the DCMs 56. 

The application 48 prepares the callback function address 
and then enters a loop to repeatedly call the media manager 
until the information on all of the DCMs 56 within the list 
is obtained. On each pass through the loop, the application 
48 makes one call to the following function: 

pascal SonyErrorResultType SMM_GetDeviceControl 
Modulelnfo (SMMDeviceListRefType theDeviceList, 
SMMDevicelndexType whichDevice, unsigned long 
reserved, SMMDeviceControlModulelteratorUPP 
theDeviceListCallbackFunction, void *userData) 

The parameter theDeviceList is the list reference that was 
returned from the function call FindAllDeviceControl 



with the device through the appropriate DCM 56. By com- 
pleting the steps illustrated in FIG. 6 and described above, 
the application 48 will have completed its startup routine 
and is now ready for operation. 

While the application 48 is operating it will be handling 
user and system level events and messages including receiv- 
ing control inputs, as well as messages from other processes, 
the host operating system and the media manager 

The present invention has been described in terms of 
specific embodiments incorporating details to facilitate the 
understanding of principles of construction and operation of 
the invention. Such reference herein to specific embodi- 
ments and details thereof is not intended to limit the scope 
of the claims appended hereto. It will be apparent to those 
skilled in the art that modifications may be made in the 
embodiment chosen for illustration without departing from 
the spirit and scope of the invention. Specifically, it will be 
apparent to those skilled in the art that while the preferred 
embodiment of the present invention is used to manage 
devices coupled together within an IEEE 1394-1995 serial 



ModulesO- The parameter whichDevice specifies which of 20 bus structure, the present invention can also be implemented 
the DCMs 56 that the application 48 is requesting informa- ' J * ~ iL ~ - L ' 

tion about. The parameter theDeviceListCallbackFunction 
includes the prepared callback function address. The param- 
eter userData is a reference to an application-defined data 
structure. This reference is passed back to the application 48 25 
in the callback routine and the application 48 will then 
transfer any needed information from the media manager to 
this data structure. 

The entire preferred sequence of the step to obtain the 
available DCMs 56 is listed in Table II below: 



to manage devices within other bus structures. 
We claim: 

1. A method of managing operation of and communica- 
tion between a network of devices for completing a task 
comprising: 

a. determining appropriate devices and subdevices 
required for completion of the task, wherein virtual 
devices are formed from available subdevices if appro- 
priate devices are not available for completion of the 
task; and 



TABLE II 



SMMDeviceListRefType theDeviceList = NULL; 

if (nil != theDeviceList) 

err = SMM_FindAllDeviceControlModu]es(&theDeviceList, kActiveDevices + klnactiveDevices, 

&gNumAvDevices); 

if (noErr ™ err) 

gAvDevicelist = NewHandle(O); 

//Prepare the callback function for the media manager: 
theDevicelnfoCallback = NewSMMDevLceControlModule[teratorProc(DeviceInfoCallbackRoutine); 
if ( (nil 1- theDevicelnfoCallback) && (nil t- gAVDevicelist) ) 
{ 

for(loop - 0; loop < gNumAvDevices; loop++) 

err - SMM_GetDeviceControlModuleInfo (theDeviceList, loop, 0, 

theDevicelnfoCallback, gAVDevicelist); 



DisposeRoutineDes criptor(theDev icelnf oCallb ack) ; 



else 



err = -1; 



void DeviceInfoCallbackRoutine(void *userData, SMMDevicelndexType devicelndex, SonyAVDeviceRECPtr 
devicetnfo) 

//Copy any information that I care about from the devicetnfo data structure 
//over to my private data referenced by userData; 
(myPiivateRecordPtr) userData->deviceID - deviceInfo->deviceID; 

} 



After the available DCMs 56 are obtained by the appli- 
cation 48, the application 48 will then obtain device specific 60 
information at the step 68. The DCM information returned 
by the media manager is system level information which 
includes the unique identifier for each device and protocol- 
specific information such as the bus generation for the IEEE 
1394-1995 devices. In order to obtain the device specific 65 
information such as status, descriptive name string and an 
image of the device, the application 48 must communicate 



b. instructing the appropriate devices and subdevices to 
complete the task. 

2. The method as claimed in claim 1 further comprising 
maintaining a control module for each device in the network, 
wherein the control module includes the capabilities of the 
device and any subdevices within the device and further 
wherein the control module is responsible for control of the 
device. 
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3. The method as claimed in claim 2 further comprising 
controlling data flow between the appropriate devices and 
subdevices. 

4. The method as claimed in claim 3 further comprising: 

a. obtaining a topology map of the devices within the 
network; and 

b. determining a best route for the data flow by analyzing 
the topology map. 

5. The method as claimed in claim 4 further comprising 
converting the data flowing between the appropriate devices 
and subdevices into a proper format, if necessary. 

6. The method as claimed in claim 5 further comprising 
providing an interface to a user through which the task to be 
completed is requested. 

7. The method as claimed in claim 6 wherein the control 
module provides user interface data to an application and 
responds to user events from the application. 

8. The method as claimed in claim 7 wherein the network 
is an IEEE 1394 serial bus network. 

9. The method as claimed in claim 7 wherein the control 
module resides in a remote device and is downloaded to a 
host device for execution. 

10. The method as claimed in claim 7 wherein the control 
module resides in a local device and is executed from a 
native environment within the local device. 

11. The method as claimed in claim 7 wherein the control 
module resides in a local device and is uploaded to a host 
device for execution. 

12. An apparatus for controlling operation of and com- 
munication between a network of devices comprising: 

a. an interface circuit configured to communicate with the 
devices within the network; and 

b. a control circuit, coupled to the interface circuit, 
configured to determine appropriate devices and sub- 
devices required for completion of a task and to instruct 
the appropriate devices and subdevices to complete the 
task, wherein virtual devices are formed from available 
subdevices if appropriate devices are not available for 
completion of the task. 

13. The apparatus as claimed in claim 12 further com- 
prising a plurality of control modules, each representing a 
device in the network, wherein each control module includes 
capabilities of a corresponding device and any subdevices 
within the corresponding device and further wherein the 
control module is responsible for control of the device. 

14. The apparatus as claimed in claim 13 further com- 
prising a bus manager circuit, coupled to the control circuit 
and to the interface circuit, configured to obtain a topology 
map of the devices within the network and determining a 
best route for data flow between the appropriate devices and 
subdevices by analyzing the topology map. 

15. The apparatus as claimed in claim 14 wherein the 
control circuit is also configured to convert the data flowing 
between the appropriate devices and subdevices into a 
proper format if data conversion is necessary. 

16. The apparatus as claimed in claim 15 wherein the 
network is an IEEE 1394 serial bus network. 

17. A method of managing operation of and communica- 
tion between a network of devices comprising: 

a. maintaining a control module for each device in the 
network, wherein the control module includes the capa- 
bilities of the device and any subdevices within the 
device and further wherein the control module is 
responsible for control of the device; 

b. providing an interface to a user through which a task to 
be completed is requested by the user; 
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c. determining appropriate devices and subdevices 
required for completion of the task by searching the 
control modules, wherein virtual devices are formed 
from available subdevices if appropriate devices are not 

5 available for completion of the task; and 

d. completing the task by instructing appropriate control 
modules to provide instructions to the appropriate 
devices and subdevices. 

18. The method as claimed in claim 18 further comprising 
10 controlling data flow between the appropriate devices and 

subdevices. 

19. The method as claimed in claim 18 further compris- 
ing: 

a. obtaining a topology map of the devices within the 
15 network; and 

b. determining a best route for the data flow by analyzing 
the topology map. 

20. The method as claimed in claim 19 further compris- 

20 ^ 

a. determining if conversion of data flowing between the 
appropriate devices and subdevices is necessary; and 

b. converting the data flowing between the appropriate 
devices and subdevices into a proper format if data 

25 conversion is necessary. 

21. The method as claimed in claim 20 wherein the 
network is an IEEE 1394 serial bus network. 

22. An apparatus for controlling operation of and com- 
munication between a network of devices comprising: 

30 a. a plurality of control modules, each representing a 
device in the network wherein each control module 
includes capabilities of a corresponding device and any 
subdevices within the corresponding device and further 
wherein the control module is responsible for control of 
35 the device; 

b. an interface configured to communicate with a user 
wherein a task to be completed is requested by the user 
through the interface; and 

c. a control circuit, coupled to the plurality of control 
40 modules, to the network and to the interface, configured 

to determine appropriate devices and subdevices 
required for completion of the task by searching the 
control modules and to complete the task by instructing 
appropriate control modules to provide instructions to 
45 the appropriate devices and subdevices, wherein the 
control circuit also determines if the appropriate 
devices and subdevices are currently available for 
completion of the task and forms virtual devices from 
available subdevices to complete the task when the 
50 appropriate devices and subdevices are not currently 
available. 

23. The apparatus as claimed in claim 22 wherein the 
control circuit is further configured to control data flow 
between the devices within the network. 

55 24. The apparatus as claimed in claim 23 further com- 
prising a bus manager circuit, coupled to the control circuit, 
configured to obtain a topology map of the devices within 
the network and to determine a best route for the data flow 
by analyzing the topology map. 
60 25. The apparatus as claimed in claim 24 wherein the 
control circuit is also configured to convert the data flowing 
between the appropriate devices and subdevices into a 
proper format if data conversion is necessary. 

26. The apparatus as claimed in claim 25 wherein the 
65 control circuit is also configured to implement pre-defined 
actions allowing users to access basic functionality of the 
devices in the network. 
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27. The apparatus as claimed in claim 26 wherein the b. means for interfacing for communicating with a user, 
control circuit is also configured to monitor and record user wherein a task to be completed is requested by the user 
activity and to create custom, user-defined actions. through the interface; and 

28. The apparatus as claimed in claim 25 wherein the c means for controUing coupled to the means for 
network is an IEEE 1394 serial bus network. 5 representing, to the network and to the means for 

29. An apparatus for controlling operation of and com- interfacing for determining appropriate devices and 
munication between a network of devices comprising: ^devices required for completion of a task by search- 

a. means for interfacing for communicating with the ing the means for representing and completing the task 
devices within the network; and ^ by instructing tnc means f or representing to provide 

b. means for controlling coupled to the means for inter- instructions to the appropriate devices and subdevices, 
facing for determining appropriate devices and subde- wherein the means for controlling also determines if the 
vices required for completion of a task and instructing appropriate devices and subdevices are currently avail- 
the appropriate devices and subdevices to complete the a bi e f or completion of the task and forms virtual 
task, wherein virtual devices are formed from available devices from available subdevices to complete the task 
subdevices if appropriate devices are not available for when the appropriate devices and subdevices are not 
completion of the task. currently available. 

30. The apparatus as claimed in claim 29 further com- 35. The apparatus as claimed in claim 34 wherein the 
prising a means for representing each device in the network means for controlling further controls data flow between the 
including the capabilities of the device and any subdevices devices within the network. 

within the device and further wherein the means for repre- 3^ The apparatus as claimed in claim 34 further com- 

senting is responsible for control of the device. prising a means for managing the network coupled to the 

31. The apparatus as claimed in claim 29 further com- means for controlling for obtaining a topology map of the 
prising a means for managing the network coupled to the devices within the network and determining a best route for 
means for interfacing and the means for controlling for data flow between the appropriate devices and subdevices by 
obtaining a topology map of the devices within the network analyzing the topology map. 

and determining a best route for data flow between the 37. The apparatus as claimed in claim 34 wherein the 

appropriate devices and subdevices by analyzing the topol- means for controlling also converts data flowing between the 

ogy map. appropriate devices and subdevices into a proper format if 

32. The apparatus as claimed in claim 29 wherein the ^ d a t a conversion is necessary. 

means for controlling also converts data flowing between the 38. The apparatus as claimed in claim 34 wherein the 

appropriate devices and subdevices into a proper format if means for controlling implements pre-defined actions allow- 

data conversion is necessary. ing users to access basic functionality of the devices in the 

33. The apparatus as claimed in claim 29 wherein the network. 

network is an IEEE 1394 serial bus network. ^ 39. The apparatus as claimed in claim 34 wherein the 

34. An apparatus for controlling operation of and com- means for controlling also monitors and records user activity 
munication between a network of devices comprising: and creates custom, user-defined actions. 

a. means for representing each device in the network 40. The apparatus as claimed in claim 34 wherein the 

including the capabilities of the device and any subde- network is an IEEE 1394 serial bus network, 
vices within the device and further wherein the means 

for representing is responsible for control of the device; ***** 
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[57] ABSTRACT 

A method and system for providing a device identification 
mechanism within a consumer electronics based audio/video 
network. Several consumer electronics products, e.g., 
television, VCR, tuner, set-top box (e.g., intelligent receiver/ 
decoder, IRD), DVTRs, PCs, DVD players (digital video 
disk), etc., can be coupled within the network to communi- 
cate together via a standard bus (e.g., IEEE 1394 serial 
communication bus). In one embodiment, the HAVI network 
offers unique advantages consumer electronic vendors 
because the architecture offers for the home network many 
of the advantages of existing computer system networks. 
Specifically, interconnected devices can share resources and 
provide open, well defined APIs that allow ease of devel- 
opment for third party developers. The present invention 
provides a mechanism whereby a global unique identifier 
(GUID) is associated with each device of the HAVI network. 
A low level driver constructs a GUID list of each device on 
the HAVI network. The order of the GUID entries in the 
GUID list (e.g., the index) matches the physical identifiers 
assigned to the devices by the 1394 serial bus. Although the 
physical identifiers can change on bus reset, the GUID 
values are constant and are used for device communication. 
Speed map and topology map information is maintained 
based on the physical identifier information and therefore 
translations between GUIDs and physical identifiers are 
efficiently performed by the present invention when refer- 
encing speed map and topology information for an applica- 
tion. 

22 Claims, 26 Drawing Sheets 
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METHOD AND SYSTEM FOR PROVIDING A 
DEVICE IDENTIFICATION MECHANISM 
WITHIN A CONSUMER AUDIO/VIDEO 
NETWORK 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates to the field of communica- 
tion systems. More specifically, the present invention relates 
to equipment for home audio/video electronics. 

2. Related Art 

A typical home audiovisual equipment complement 
includes a number of components, e.g., a radio receiver, a 
CD player, a pair of speakers, a television, a VCR, a tape 
deck, etc. Components are connected to each other via sets 
of wires. One component is usually the central component of 
the home audiovisual system. This is usually the radio 
receiver, or the tuner/decoder. The control buttons and 
control switches are usually located on the front of the tuner 
and in many cases, some or all of these buttons and switches 
are duplicated on a hand held remote control unit. A user 
controls the home equipment by manipulating the buttons 
and switches on the front of the tuner, or alternatively, 
manipulating buttons on the hand held remote control unit. 

As consumer electronic devices have become more 
capable and more complex, demand for the latest and most 
capable devices has increased. As new devices emerge and 
become popular, new devices are purchased by consumers 
and "plugged" into their home audiovisual systems. The new 
device is simply plugged into the system alongside the 
pre-existing, older devices (e.g., cassette tape deck, CD 
player, and the like). The new device is plugged into an open 
input on the back of the tuner, or some other device coupled 
to the tuner. The consumer (e.g., the user) controls the new 
device via control switches on the new device itself, or via 
a separate remote control unit for the new device. 

As the number of new consumer electronics devices for 
the home audiovisual system has grown and as the sophis- 
tication and capabilities of these devices have increased, a 
number of problems with the conventional paradigm 
emerge. One such problem is incompatibility between 
devices in the home audiovisual system. In addition, where 
one device is much newer than another device additional 
incompatibilities may exist. For example, a new device 
might incorporate hardware (e.g., specific inputs and 
outputs) which enables more sophisticated remote control 
functions. This hardware may be unusable with older 
devices within the system. Another problem is the lack of 
functional support for differing devices within an audiovi- 
sual system. For example, even though a television may 
support advanced sound formats (e.g., surround sound, 
stereo, etc.), if an older less capable tuner does not support 
such functionality, the benefits of the advanced sound for- 
mats can be lost. Another problem is the proliferation of 
controls for the new and differing devices within the home 
audiovisual system. Each new device coupled to the audio- 
visual system often leads to another dedicated remote con- 
trol unit for the user to keep track of and learn to operate. 

In view of the above, it is desired to provide a commu- 
nication architecture in which consumer electronics devices 
can be integrated. In so doing, the consumer electronics 
devices can offer and be expanded to include advanced 
communications and control functionality between them- 
selves not heretofore offered. Within such communication 
architecture integrating consumer electronic devices ("a 
consumer's electronics network"), devices can communi- 
cate with each other and control one another. 



,038,625 

2 

The IEEE 1394 serial communication bus, according to 
the IEEE 1394 standard, assigns a 6 -bit physical identifier 
value (phy_Jd) to each device connected to the bus. The 
IEEE 1394 serial communication bus uses this physical 
S identifier to communicate with a device coupled thereto. 
Whenever a new device is inserted onto the bus, or an 
existing device is removed from the bus, or both, a bus reset 
is caused. The bus reset initiates certain well known bus 
recovery communications and functions in accordance with 
io the IEEE 1394 standard, including the possible renumbering 
of the physical identifiers of the devices remaining on the 
IEEE 1394 bus. That is to say, the physical identifiers 
assigned to devices on the IEEE 1394 bus are not persistent. 
However, it is also desired within the consumer electron- 
15 ics network that high level applications adopt abstract and 
persistent identifiers for devices coupled to the IEEE 1394 
communication bus. Since many data structures (e.g., speed 
map and topology map) and communications channels are 
maintained and implemented within the IEEE 1394 standard 
20 using physical identifiers, a problem exists for high level 
applications that use a persistent identifier for each device 
but need to communicate with devices and/or require speed 
map and topology map information. What is needed is a 
mechanism and method operable within a consumer elec- 
25 tronic network that provides an IEEE 1394 communication 
framework, but also provides high level applications with a 
persistent identifier for devices coupled to the network. 
What is desired further is an efficient mechanism operable 
within a consumer electronic network that provides an IEEE 
30 1394 communication framework, but also provides high 
level applications with a persistent identifier for devices 
coupled to the network. 

SUMMARY OF THE INVENTION 
35 Accordingly, the present invention provides an efficient 
mechanism and method operable within a consumer elec- 
tronic network that provides an IEEE 1394 communication 
framework and also provides high level applications with a 
persistent identifier for devices coupled to the network. The 
4 0 present invention provides such advantageous functionality 
utilizing global unique identifiers (GUIDs) assigned to each 
device of the consumer electronics network. A GUID map is 
constructed and maintained upon each bus reset that maps 
GUID values with physical identifier values. These and 
45 other advantages of the present invention not specifically 
mentioned above will become clear within discussions of the 
present invention presented herein. 

A method and system are described herein for providing 
a device identification mechanism within a consumer elec- 
50 tronics based audio/video network. Within the network, 
several consumer electronics products, e.g., television, 
VCR, tuner, set-top box (e.g., intelligent receiver/decoder, 
IRD), DVTRs, PCs, DVD players (digital video disk), etc., 
can be coupled to communicate together via a standard bus 
55 (e.g., IEEE 1394 serial communication bus). This allows 
devices of the network to control one another and obtain 
information regarding one another. In one embodiment, the 
communication architecture used is the home audio/visual 
initiative (HAVI) format. The HAVI network offers unique 
60 advantages consumer electronic vendors because the archi- 
tecture offers for the home network many of the advantages 
of existing computer system networks, namely, intercon- 
nected devices can share resources and provide open, well 
defined APIs that allow ease of development for third party 
65 developers. HAVI offers extended interoperability. 

The present invention provides a mechanism whereby a 
global unique identifier (GUID) is associated with each 
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device of the HAVI network. A low level driver, a link 
driver, constructs a GUID list including a GUID for each 
device on the HAVI network. The order of the GUID entries 
in the GUID list (e.g., the index) matches the physical 
identifiers assigned to the devices by the IEEE 1394 serial 
bus. Although the physical identifiers can become reas- 
signed on bus reset, the GUID values are constant. Within 
the present invention, network-based applications use a 
device's GUID to communicate therewith. Speed map and 
topology map information is maintained based on the physi- 
cal identifier information. Therefore translations between 
GUIDs and physical identifiers are efficiently performed by 
the present invention and are used for referencing speed map 
and topology information for an application program or 
other object. 

The 1394 local bus architecture creates a dynamic net- 
work within which a 1394 capable device can be inserted 
(e.g., hot insertion) at any time and be ready for use. Within 
the local bus system, a device is identified with a 6-bit 
physical identification number (phy_id) which is assigned 
by the local bus upon a bus reset. The phy_id for a device 
can change as new devices are added into or existing devices 
are removed from the network. To provide higher level 
applications with a persisting identifier for a given device, 
the GUID (global unique identifier) is employed by the 
present invention. The GUID is a unique 64 bit value that 
contains a vender identification number coupled with a chip 
series identification number. The GUID is determined 
(according to IEEE 1212 standards) when an IEEE 1394 
capable device is manufactured. Because some bus 
information, such as speed map and topology map, are 
referenced by physical identifier values, the present inven- 
tion provides an efficient mechanism for presenting speed 
map and topology map information with respect to the 
corresponding GUID value for a device. 

A list of available devices in the network is information 
that network-based applications generally request periodi- 
cally. The present invention generates and maintains a GUID 
list of all devices of the network and orders the GUIDs of the 
GUID list by their respective physical identifier values. In 
this manner, the index of a particular GUID within the GUID 
list is its physical identifier and this index can be obtained 
and then used to access data from the speed map and 
topology map data structures which are constructed and 
maintained with respect to physical identifier values. For 
instance, if the speed between devicex (GUID1) and devicey 
(GUID2) is needed, the present invention locates the index 
values, indexl and index2, for GUID1 and GUID2 using the 
GUID list. Indexl and index2 are then used to access the 
speed map data structure and the desired speed data is 
returned to higher level applications. Alternatively, the entire 
speed map or topology map can be presented to the higher 
level application along with the current GUID list and the 
application can perform the indexing for the desired data. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1A illustrates a physical port connection topology of 
an exemplary device configuration of the home audio/visual 
initiative (HAVI) consumer electronics network in accor- 
dance with the present invention. 

FIG. IB illustrates a local bus connection topology of the 
exemplary device configuration illustrated in FIG. 1A in 
accordance with the present invention. 

FIG. 1C illustrates a communication channel topology 
with respect to once device coupled to the HAVI network 
illustrated in FIG. lAin accordance with the present inven- 
tion. 
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FIG. 2 illustrates internal circuitry of an intelligent 
receiver/decoder device of the HAVI network of FIG. 1A 
(acting as a full audio/visual, FAV 7 node) in accordance with 
the present invention. 
5 FIG. 3 illustrates a complement of software services made 
available by a full audio/visual (FAV) node of the HAVI 
network in accordance with the present invention. 

FIG. 4 illustrates communication pathways within the 
HAVI software architecture in accordance with the present 
10 invention. 

FIG. 5A illustrates communication flow to the communi- 
cation media manager (CMM) of the present invention from 
various software objects. 
15 FIG. SB illustrates communication flow to various soft- 
ware objects from the communication media manager 
(CMM) of the present invention. 

FIG. 6 illustrates the IEEE 1394 local bus interface (e.g., 
MPEG/MV Link) with CMM in the HAVI architecture. 
20 FIG. 7A and FIG. 7B illustrates steps performed within 
the HAVI architecture to implement message communica- 
tion between devices. 

FIG. 8 illustrates communication pathways between an 
application, a device control module (DCM), the CMM and 
25 a link driver in accordance with the present invention. 

FIG. 9 A is an illustration of a physical identifier indexed 
topology map data structure used by the present invention. 

FIG. 9B and FIG. 9C illustrate, respectively, one dimen- 
sional and two dimensional physical identifier indexed speed 
30 map data structures as used by the present invention. 

FIG. 10A shows a first exemplary device network con- 
figuration within the HAVI architecture. 

FIG. 10B shows a second exemplary device network 
35 configuration within the HAVI architecture. 

FIG. 11A illustrates a GUID list as constructed by one 
embodiment of the present invention for the first exemplary 
device network configuration of FIG. 10A. 

FIG. 11B illustrates a GUID list as constructed by one 
40 embodiment of the present invention for the second exem- 
plary device network configuration of FIG. 10B. 

FIG. 12A illustrates a general GUID update status list 
constructed by a second embodiment of the present inven- 
tion in response to the device network configurations of FIG. 
45 10A and FIG. 10B. 

FIG. 12B illustrates an "added" GUID update status list 
constructed by a second embodiment of the present inven- 
tion in response to the device network configurations of FIG. 
10A and FIG. 10B. 
50 FIG. 12C illustrates a "removed" GUID update status list 
constructed by a second embodiment of the present inven- 
tion in response to the device network configurations of FIG. 
10A and FIG. 10B. 
ss FIG. 13 is a flow diagram illustrating steps performed by 
the present invention for constructing a GUID list in 
response to a local bus reset. 

FIG. 14 is a flow diagram illustrating steps performed by 
the present invention for constructing and communicating 
60 the GUID update status lists in response to a local bus reset. 
FIG. 15A is a flow diagram illustrating the use of the 
GUID list in accordance with the present invention for 
sending a message to a device. 

FIG. 15B illustrates the use of the GUID list to provide an 
65 index in accordance with the present invention for accessing 
the speed map to determine communication speed informa- 
tion. 



03/22/2004, EAST Version: 1.4.1 



6,038,625 

5 6 

FIG. 15C illustrates the use of the GUID list to provide an initiative (HAVI) architecture. Aspects of the HAVI archi- 

index in accordance with the present invention for accessing tecture network (e.g., "HAVI architecture") are discussed to 

the topology map to determine topology information. provide a general framework in which embodiments of the 

FIG. 15D illustrates the use of the GUID list to provide an P resenl invention operate, 

index in accordance with the present invention for accessing * , * ™ . architecture for mter-operaurig consumer 

the speed map to determine communication speed informa- electronics equipment devices adapted for the home net- 

tion where the application references the speed map. ^ 

FIG. 15E illustrates the use of the GUID list to provide an the home A feature of the j^yj arc hitecture is the combi- 

index in accordance with the present invention for accessing nat j on 0 f a 5^ ^ 0 f generic device controls (a device 

the topology map to determine topology information where control software module) with a method to extend the base 

the application references the topology map. control protocol as new features and devices are deployed. 

DETAILED DESCRIPTION OF THE . ^'.W 1 a , rchitecture supports a wide range of devices 

INVENTION including intelligent receiver/decoders (IRDs), digital video 

15 tape records (DVTRs), video cassette recorders (VCRs), 
In the following detailed description of the present personal computers (PCs), digital video disk players 
invention, a method and system for providing efficient (DVDs), etc., communicating via a common messaging 
device identification using a GUID list within a consumer system. FIG. 1A illustrates the physical port-to-port con- 
electronics based audio/video network, numerous specific necting configuration 10a of an exemplary HAVI network, 
details are set forth in order to provide a thorough under- 2Q Several consumer electronics devices ("devices") 12-24 are 
standing of the present invention. However, it will be shown connected together with bus segments 30a-30/ which 
recognized by one skilled in the art that the present invention couple ("plug into") to ports on the respective devices. In 
may be practiced without these specific details or with one embodiment of the HAVI architecture, the IEEE 1394 
equivalents thereof. In other instances, well known methods, serial communication bus standard is used as a local bus 
procedures, components, and circuits have not been 25 platform to provide the common messaging system. The 
described in detail as not to unnecessarily obscure aspects of IEEE 1394 serial communication bus carries both 
the present invention. commands, status information and well as digital audio and 

digital video signals between devices. 

NOTATION AND NOMENCLATURE 6 plG lfi a ^ bu$ m of the 

Some portions of the detailed descriptions which follow 30 HAVI network of FIG. 1A. As shown in FIG. IB, all of the 
are presented in terms of procedures, steps, logic blocks, devices 12-24 of the HAVI network can be viewed as 
processing, and other symbolic representations of operations logically coupled to a common IEEE 1394 serial commu- 
on data bits within a computer memory (see FIG. 2). These nication bus 30. Within this bus configuration 10b, peer-to - 
descriptions and representations are the means used by those peer device communication is supported. For example, as 
skilled in the data processing arts to most effectively convey 35 shown in FIG. 1C, any device (having appropriate 
the substance of their work to others skilled in the art. A capabilities), e.g., device 12, can send or receive commu- 
procedure, computer executed step, logic block, process, nication packets from any other device in the HAVI network, 
etc., is here, and generally, conceived to be a self-consistent In the example of FIG. 1C, the set-top-box (e.g., an IRD) can 
sequence of steps or instructions leading to a desired result. receive messages from or generate messages to any of the 
The steps are those requiring physical manipulations of 40 other devices 14-24 of the exemplary HAVI network, 
physical quantities. Usually, though not necessarily, these The interoperability model in the HAVI architecture pro- 
quantities take the form of electrical or magnetic signals vides for the following: 1) support for existing devices; 2) a 
capable of being stored, transferred, combined, compared, default control model; 2) a means to extend the default 
and otherwise manipulated in a computer system. It has control model when new devices or functionality is brought 
proven convenient at times, principally for reasons of com- 45 to market; and 4) a common means for device representation 
mon usage, to refer to these signals as bits, values, elements, (e.g., graphics user interfaces). To achieve the above, the 
symbols, characters, terms, numbers, or the like. HAVI architecture defines three types of nodes in the home 

It should be borne in mind, however, that all of these and network. A base AV (BAV) node is defined for devices that 

similar terms are to be associated with the appropriate already exist in the market (e.g., VCR 22 of FIG. 1A). An 

physical quantities and are merely convenient labels applied 50 intermediate AV (LAV) node is defined for simple devices 

to these quantities. Unless specifically stated otherwise as such as camcorders or DVTRs (e.g., camera 14). A full AV 

apparent from the following discussions, it is appreciated (FAV) node is defined for devices of more resources, such as 

that throughout the present invention, discussions utilizing IRDs or smart televisions (e.g., set-top-box 12). An FAV 

terms such as "processing" or "computing" or "translating*' node (or device) typically contains enough hardware to host 

or "calculating" or "determining" or "displaying" or "rec- 5s control modules and to support application programs locally, 

ognizing" or the like, refer to the action and processes of a The LAV devices and FAV devices communicate by sending 

computer system, or similar electronic computing device, messages over the home network using a generic message 

that manipulates and transforms data represented as physical passing system described more fully below. When new 

(electronic) quantities within the computer system's regis- devices join the home network, they are recognized and 

ters and memories into other data similarly represented as 60 added to a global name database (registry). The registry 

physical quantities within the computer system memories or holds information about their characteristics and provides a 

registers or other such information storage, transmission or reference to a handler (e.g., communication point) for that 

display devices. device. Other devices and services are able to query the 

registry to locate a device and then, using the handler, can 

HAVI ARCHITECTURE GENERALLY fi5 mte ract with the device. 

Embodiments of the present invention are operable within When a device is initially added to the home network, the 

a consumer electronics network of the home audio/visual system queries the device to ascertain its characteristics and 
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capabilities. Once a device's characteristics are known, the provide a platform for certain HAVI software (described 

architecture provides two methods of controlling it. The first below). For instance, the set-top-box 12 device of the 

method, level one interoperability, uses a predefined mes- exemplary HAVI network of FIG. 1A contains special 

sage set based on IEEE 1394 AV/C-CTS. All IAV and FAV hardware components that provide an operation platform for 

nodes can use this command set to access and control other 5 software components of the HAVI architecture. Another 

devices, however, BAV nodes, because they are deployed example of an FAV is a digital television having the required 

before the architecture was defined, are controlled using hardware resources to support HAVI software. Certain 

legacy protocols. The level one interoperability provides a aspects of the present invention, described below, are dis- 

default level of control. The FAV nodes act as control nodes cussed in terms of steps exeai ted on a computer system 

and create a local representation of the IAV node, known as 1Q , proC csses 400, 700, 800, 850, 900a, 950a, 900fc and 

a device control module (DCM), that provides an API used 9SOb) Mihou ^ a variety of differerjt computer systems can 

to send control commands to the device. be used ^ ^ { {nvcQiiojlt an exemp i ary general 

Uvel two interoperability within the HAVI architecture purpose computer system is shown in the set-top-box FAV of 

goes farther and supports future added functionality and new 2 

devices. To achieve this, a particular device can carry within ' ' , . ... 

its ROM an override DCM that is uploaded from the IAV 15 Set-top-box 12 of FIG. 2, in addihon to having a video/ 

device, to the FAV device, and replaces the default DCM for ™ dl ° receiver (decoder) unit 106 and MPEG unit 107 also 

the particular device. This override DCM not only contains includes an internal address/data bus 100 for communicating 

the basic level one command set for the particular device but information, one or more central processors 101 coupled 

also includes vendor specific commands to control advanced with the bus 100 for processing information and 

features of the device. This model allows the device to 20 instructions, a volatile memory 102 (e.g., random access 

inform another object about its particular functionality. memory RAM) coupled with the bus 100 for storing infor- 

Since the override DCM may be loaded onto any vendor's mation and instructions for the central processor 101 and a 

FAV, the format of the DCM is architecture-neutral. non-volatile memory 103 (e.g., read only memory ROM) 

To allow one device to discover the capabilities of another coupled with the bus 100 for storing static information and 

device and to determine which command set to use with that 25 instructions for the processor 101. Set-top-box 12 can also 

device, a standard device description structure is provided optionally include a data storage device 104 ("disk 

called the self describing data (SDD) structure. The SDD subsystem") such as a magnetic or optical disk and disk 

data structure is extensible. It can be a small number of bytes drive coupled with the bus 100 for storing information and 

describing the device type, e.g., TV, or VTR, etc. instructions. Also included in the set-top-box 12 is a bus 

Alternatively, the SDD data structure can be a more complex 30 mtcr f acc un j t 108 for interfacing with the local bus 30 (e.g., 

structure also defining the override DCM and a graphical an 1£EE 1394 bus ) Set-top-box 12 can operate under 

representation of the device. The graphical representation var[ of d[EcKni operat i D g systems (e.g., Windows 

within the SDD data structure allows an FAV node to present ^ DOS operating system, Macintosh O/S), 

a pictonal representation of the devxees in the home network * J* embodiment ^^os operating system is used, 
to users. 

By defining the graphical representation in a sufficiently HAVI SOFTWARE ARCHITECTURE 

generic manner, a device's SDD graphical data can be used In one embodiment, the software of the HAVI architecture 

in any vendor's product to display (e.g., on a television or cafl be broken into three api s (AVOS, interoperability and 

monitor within the network) a user interface for that device. app Lj C ation). The AVOS API is a low level system API that 

This provides an enhanced level [of vendor mteroperabdity ^ common ti tem serviceS) c<g 

and also allows a vendor to differentiate mread communicationS) and memory . interoperability 

rr^s^ ^ e r a ^ 

node) to present a general control user interface for all P«vidc a basic representation model and a means to extend 

devices in the home network, irrespective of the differences the control model with vendor specific commands The 

in type and vendor. Self describing data (SDD) is described 45 application API is a high level API for applications including 

in copending provisional application serial number 60/054, interactive TV applications, and in one embodiment is based 

327, eotided "A Method and Apparatus for Including Self- on the DAVIC API set including the Motion Hypermedia 

Describing Information within Devices," filed Jul. 31, 1997 Expert Group (MHEG) interactive application engine, 

and assigned to the assignee of the present invention. The FIG. 3 illustrates the software architecture 200 used in the 

above referenced provisional patent application is hereby 50 HAVI architecture in more detail. The architecture 200 

incorporated by reference. contains several generic components to provide abstractions 

Legacy devices are devices that were built before the of common facilities in the home network. A communication 

HAVI architecture or devices that select not to use the HAVI media manager 250 is provided and this component 

architecture. The HAVI architecture supports Legacy abstracts from the underlying transport network. In the case 

devices by providing Legacy DCMs to provide protocol 55 of ^ 1394> the communication media manager 250 

conversions for Legacy devices. These Legacy DCMs can maintains and generates information regarding the speed 

contain sufficient knowledge to allow them to support an maps 515 ( FIG md topology maps 520 which are used 

existing 1 or 2 way control protocol and provide a specific , embodiments of the present invention. A DCM Manager 

control interface to the devices that conform to the HAVI ided ^ fe si51e fof identifying and 

architecture. A legacy DCM acts as a bridge be ween the * one bilit 

Legacy and HAVI devices. This feature allows the HAVI ou _ , -_ A . . , ^xxJ^^Ja 

architecture also to interact with any future device control J* D ™ Managw 270 also hosts overr.de DCMs uploaded 

protocols such as, for example, protocols being used for *™ °5 °' he ' Sl,es - A Gra P hlcs Management urn 

home energy management or security, etc. 220 ,. ls provided which supplies generic graph.es APIs that 

BJ ^ J applications and DCMs can use to present user interface 

SET-TOP-BOX 12 OF FIG. 2 65 information. 

Any consumer electronics device can be provided with A Stream Manager 335 of FIG. 3 is used to determine the 

the appropriate hardware to act as an FAV and thereby most effective route for AV streams within the home net- 
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work. A data format manager is included within the Stream 
Manager 335 and is responsible for providing conversion of 
AV streams to and from various formats as they flow 
between devices in the home network. These operations are 
described below with reference to FIG. 7A and FIG. 7B. A 5 
Messaging Manager 212 supports a generic messaging 
mechanism that allows devices to locate and interact with 
other devices in the home network, A communications 
media manager (CMM) 250 is a media dependent entity in 
the HAVI software architecture 200. The CMM 250 pro- 
vides abstract services to other HAVI components or appli- 
cation programs in the HAVI network. It also provides 
media specific transport mechanisms for actual data com- 
munication among various devices in the home network. 
The CMM 250 is responsible for compiling new GUID 
status updates upon a local bus reset. It is appreciated that 15 
each physical communication media contains its own CMM 
to serve the above purposes. As one example, the CMM 250 
for the IEEE 1394 serial bus is described herein further 
below. 

The Event Manager 214, the Registry 216, the Stream 20 
Manager 335 and the Initialization Manager 210 of FIG. 3 
are described separately further below. 

FIG. 4 illustrates a data flow diagram 305fl with the HAVI 
software architecture 200 including an interface with the 
local bus HAL layer 330 for local bus 30. In diagram 305a, 25 
the top layer is an application program layer ("application 
layer") 220 which can communicate with a function control 
module (FCM) layer 314 having AVIC command. The 
application layer 220 resides within a FAV and can also 
communicate with device control modules (DCMs) 230 and 30 
with the Registry 216. The application layer 220 commu- 
nicates with a Stream Manager 335. The DCMs 230 are 
controlled by the DCM manager 270 which can communi- 
cate with the Event Manager 214. The Event Manager 214 
communicates with the CMM 250. The Stream Manager 335 35 
allows communication between the application layer and the 
CMM 250. The AV Messenger unit 212 also communicates 
with the CMM 250. The CMM 250 provides an interface 
with the local bus interface 330 via a link driver unit 320. 
The link driver unit 320 is responsible for compiling new 40 
GUID lists upon a local bus reset. Higher level applications 
are located with block 310 and lower level applications 
within block 312. A subset of this communication diagram 
305a is illustrated in FIG. 8. 

FIG. 5A is a diagram 340a that illustrates communication 45 
channels that are available for communicating to the CMM 
250. The application layer 220 communicates with the 
CMM 250 to obtain bus generation information, to obtain 
the GUID list, to obtain the speed map 515 and to obtain the 
topology map 520. The following APIs are used to perform 50 
these functions: getGUIDList( ); getBusGeneration( ); 
getSpeedMap( ); and getTopologyMap( ). The ilink trans- 
portation adaptation module, TAM, 2126 communicates 
with the CMM 250 for asynchronous requests and asyn- 
chronous responses. The digital I/F controller 335a commu- 55 
nicates with the CMM 250 for asynchronous requests, 
asynchronous responses, channel allocations, channel 
deallocations, bandwidth allocations and bandwidth deallo- 
cations. The Stream Manager 335 utilizes GUID informa- 
tion to establish point to point communications via the 60 
digital I/F controller 335a. The digital I/F controller 335a 
communicates with the CMM 250 using the following APIs: 
allocateChannel( ); deallocateChannel( ); 
allocateBandwidth( ); and deallocateBandwidth( ). The iso- 
chronous data transceiver 230 is a DCM and communicates 65 
with the CMM 250 using the following APIs: isoOpen( ); 
isoClose( ); isoAttach( ); isoDetach( ); and isoControl( ). 
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FIG. 5B is a diagram 3406 that illustrates communication 
channels that are available for communicating from the 
CMM 250 to other objects. The CMM 250 communicates 
bus reset indications to the Event Manager 214. The CMM 
250 also communicates status information regarding the set 
of current devices on the local bus 30 including information 
as to which devices are added and which devices have been 
removed from the local bus 30 since the last GUID list was 
constructed. The CMM 250 also communicates bus reset 
information to the ilink TAM 2126 as well as GUID 
information, asynchronous receive, and isochronous 
receive. This same information is also communicated from 
the CMM 250 to the isochronous data transceiver module 
230. Information regarding which devices are coupled to the 
local bus 30 is also communicated from the CMM 250 to the 
digital I/F controller 335a. 

FIG. 6 illustrates an exemplary interface 360 between the 
CMM 250 and the local bus 30 for IEEE 1394 interfacing. 
A 1394 Bus Manager 370 is also shown. The CMM 250 
contains a copy of the speed map 515 and the topology map 
520 (described further below) and and IEEE 1394 Bus 
Manager 370 contains control/status registers (CSRs). The 
isochronous resource manager 372 contains information 
regarding the bus master identification and the available 
channels and bandwidth for communication via isochronous 
registers (CSRs). The node controller 374 contains a con- 
figuration ROM as well as node control registers (CSRs). 
Units 250, 372 and 374 constitute the serial bus management 
unit 370. Unit 370 communicates with 1394 HAL interface 
(I/F) layer 330. The transaction block 378 processes read/ 
write/lock transactions, tracks pending transactions and con- 
trols retry protocol operations with a busy/timeout register. 
Data transmission takes place within the link layer 380 and 
the I/F (CFR) unit 385. 

DCM 230 AND DCM MANAGER 270 

A description of the DCM 230 and the DCM manager 270 
of FIG. 3, as well as other aspects of the HAVI software 
architecture 200 are described in copending U.S. patent 
application Ser. No. 09/003,119, entitled "A Home Audio/ 
Video Network with Iwo Level Device Control", by R. Lea 
and A. Ludtke, filed concurrently herewith, attorney docket 
No. SONY-50L2278, assigned to the assignee of the present 
invention and hereby incorporated herein by reference. 

THE COMMUNICATIONS MEDIA MANAGER 
250 

The CMM 250 (e.g., for the IEEE 1394 bus) of FIG. 4 
provides two levels of APIs. One is the high-level API that 
interacts with other HAVI components to offer abstract 
services such as topology map 520 and speed map 515 as 
well as generating HAVI related events. The other level of 
APIs is the low-level API that provides a basic transport 
mechanism for both asynchronous and isochronous data 
transfers. Normally, high-level APIs are available to any 
HAVI entity or applications residing locally on this same 
node, while the low-level APIs presents the primary inter- 
face to the IEEE 1394 bus 30 so that specific protocols can 
be built on top of the CMM 250. To access high-level APIs, 
the HAVI message system (e.g., AvMessenger 212) is used, 
whereas access to low-level APIs can be accomplished 
through direct calls to the CMM 250. 

The messaging used to access high-level APIs through 
HAVI message system is done using a format having a 
multi-byte selector followed by function dependent param- 
eters. Tne function selector determines which service to use 



03/22/2004, EAST Version: 1.4.1 



6,038,625 



11 



12 



from the CMM 250, and the parameters section provides all 
required parameters for the specified function. To invoke 
low-level APIs, only the parameters section is necessary. 

The IEEE local bus 30 is a dynamically configurable 
network. After each bus reset, a device can have a complete 
different physical identifier (phy_id) than it had before the 
bus reset. If a HAVI component or an application has been 
communicating with a device in the HAM network it 
generally desires to continue the communication after a bus 
reset even though the device may have a different physical 
identifier. To identify a device uniquely regardless of fre- 
quent bus resets, the present invention provides the Global 
Unique ID (GUID) which is used by the CMM 250 and other 
HAVI entities. A GUID is a multi-bit number (e.g., 64-bits 
in one implementation) that is composed of 24 bits of 
node-vendor identification and 40 bits of chip (series) iden- 
tification. While a device's physical identifier may change 
constantly, its GUID is permanent within the HAVI archi- 
tecture. The CMM 250 of the present invention makes 
device GUID information available for its clients using a 
GUID list discussed further below. 

The CMM 250 abstracts the underlying device intercon- 
nection mechanism, providing a common set of API's to 
describe the capabilities of the bus architecture. In one 
embodiment, the CMM concept is driven by the IEEE 1394 
bus model, but is sufficiently abstract to provide a general 
service for interconnection management. The CMM 250 
provides APIs for 4 four basic concepts. (1) Channel: a 
channel is a logical data connection that a bus can support. 
For technology such as IEEE 1394, this maps directly to 
hardware support for multiple channels. For technology that 
only supports a single data connection, then this degenerates 
to a single channel. (2) Bridge: a bridge is a connection 
between two bus technologies and allows channels to span 
different bus technologies. (3) Node: a node is a physical 
endpoint for a channel and corresponds to a unit or subunit 
in the HAV architecture. (4) Bandwidth: this is a metric of 
how much data can be carried on a bus at any one time. 
Bandwidth can be assigned to channels to support the 
required data rates for whatever data the channel is deliv- 
ering. 

For those bus protocols which do not support these 
concepts, the results of API calls to their CMMs have limited 
results. For example, if a particular bus technology does not 
support multiple simultaneous data transfer actions, then it 
most likely reports only a single "channel," even though it 
does not really support channels. The CMM 250 maps 
transactions to the channel model. 

There is one CMM 250 for each physical interface (e.g. 
1394, Control Al, TCP/IP) on a FAV node. Because there 
can be more than one kind of CMM 250, and because there 
can be many of them in existence, each CMM 250 has a 
module_type attribute attached to its entry in the Service 
Registry 216 database. The definition of this attribute can be 
as follows: 

module„type»busManager 

module_data={l394, Control Al, TCP/IP, etc.} These 
bus types will have numeric identifiers defined for 
them. 

Each CMM 250 contains the general set of API's for bus 
management, as well as protocol-specific API's. If a par- 
ticular bus technology supports features that are above and 
beyond the general model, then it can subclass the CMM 
base class and add the new functionality. For example, the 
1394 CMM 250 allows access to the 1394-specific bus 
attributes such as the isochronous resource manager. Those 
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clients who are 1394-aware, and need such capabilities, can 
go through the 1394 CMM 250. 

One of the advanced features the 1394 bus provides to the 
HAVI architecture is its support for dynamic device actions 
such as hot plugging (device insertion or power up) and 
unplugging (device removal or power down). To fully 
support this to the user level, high level software clients need 
to be aware of these environment changes and the present 
invention provides this information. The CMM 250 works 
with the Event Manager 214 to detect and announce these 
dynamic bus changes using device status tables (FIG. 12A, 
FIG. 12B, FIG. 12C). Since any topology change within 
1394 bus will cause a bus reset to occur, the CMM 250 is 
informed of these changes and notifies the Event Manager 
214 of these changes along with the information about 
devices that have disappeared as well as those that have 
become available. The Event Manager 214 then distributes 
the related event to all interested HAVI entities or applica- 
tions that previously established the proper call back han- 
dlers. 

There are two basic types of events that are generated 
from the CMM 250 to support dynamic updating of avail- 
able devices in the network One is NEW__DEVICE which 
indicates a new device, and the other is GONE_DEVICE, 
indicating a device has been removed. To increase efficiency, 
the CMM 250 generates device status tables with this 
information. Whenever a device is added or removed from 
the network, a bus reset is generated and CMM 250 finds and 
passes a status table of new/gone devices to the Event 
Manager 214 if the Event Manager 214 has requested such 
service. Since NEW__DEVICE or GONE_DEVICE also 
indicates the occurrence of a bus reset, the Event Manager 
214 may also create a BUS__RESET event based on the 
above information. It should be noted that all these events 
are generally "local," which means that the Event Manager 
214 does not generally send/broadcast such events to any 
other nodes. 

The CMM 250 also provides topology, speed maps, and 
other environment descriptions to its clients. The topology 
map 520 (FIG. 9A) depicts the connectivity among physical 
devices. Within the present invention, it can be used to build 
a human interface that helps the user understand how 
devices are connected and how certain features may be used. 
The speed map 515 (FIG. 9B, FIG. 9C) provides information 
on the possible maximum speed that can be used for data 
transmission between any two devices in the network. Speed 
maps provide information about the connectivity and per- 
formance of sections of the HAV network. It can be used to 
analyze the current connection scheme and give the user 
helpful suggestions for improving the performance of 
devices by rearranging the connections. If attributes such as 
the topology map 520 cannot be automatically generated, 
then a dialog with the user may be required. When a 
topology request is made to a CMM for a protocol that does 
not support automatic topology detection, the request can 
trigger such a dialog. After interacting with the user to 
determine how its devices are connected, the CMM returns 
the requested information. 

Topology map 520 and speed map 515 may change 
constantly because their organization (e.g., data order) is 
based on the physical identifiers of the devices on the 
network and these values can become reassigned due to the 
allowed dynamic insertion or removal of devices. To iden- 
tify the right "version" for these maps, a bus generation 
number may be used. Newer bus generation values signify 
the change of bus configuration. It may also be used to check 
if a pending operation is "stale". Since transactions between 
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devices require the existence of those devices, it is possible 
that a pending transaction has not yet completed and one or 
more devices involved have gone away. When this happens, 
a new bus generation number will be generated and the 
related process can check against this new generation num- 5 
ber to make proper clean up for the stale transaction. 

Bus generation number, topology map 520, and speed 
map 515 remain unchanged between bus resets. To improve 
efficiency, the CMM 250 may optionally cache them inter- 
nally and keep them updated only when bus reset occurs. 10 

Another feature of the IEEE 1394 bus 30 is its capability 
to send timingcritical stream through its isochronous chan- 
nels. To send data in isochronous mode, channel number and 
proper bandwidth need to be allocated from the bus. The 
CMM 250 provides such services to allocate/deallocate is 
channel numbers and bandwidth for its clients. It is also 
responsible to restore these resources for its clients right 
after each bus reset so that any existing isochronous data 
transaction will not be disrupted because of the unavailabil- 
ity of these resources. 20 

The CMM 250 also provides a transport mechanism to 
actually transfer the data, which is part of low-level services. 
There are two types of data transactions with IEEE 1394 bus 
30. One is asynchronous, the other isochronous. Typical 
asynchronous transfer includes quadlet/block write, quadlet/ 25 
block read, and lock operations. Typical isochronous data 
transfer normally involves allocating channel/bandwidth, 
opening isochronous data port, attaching data buffer(s), and 
activating data transfer. These services provide a fundamen- 
tal transport mechanism for a 1394 based HAVI system 30 
being functional. 

The following APIs are provided by IEEE 1394 specific 
CMM 250 within the present invention: 

1) CMM::enrollComeNGo( ) 

Status: enrollComeNGo(ObjectID oid, (void *) (*) 35 
callbackjiandler) 

This command is used by the Event Manager 214 to get a list 
of new and removed devices when bus reset occurs. The 
Event Manager 214 enrolls such request to the CMM 250 to 
get the service. The parameter oid is the caller's object 40 
identifier and callback__handler is the callback function 
provided by the caller. The caller (typically Event Manager 
214) enrolls its OID and a callback handler to the CMM 250 
so that when bus reset occurs, the CMM 250 invokes the 
callback function with a list of devices (device status table) 45 
that are either new or gone. 

2) CMM::getGUIDList( ) 

Status: CMM 250: :getGuIDList(GUID *guid) 

This command gets the GUID for all active devices in the 

network. The parameter guid is a pointer to a the GUID list. 50 

3) CMM::getBusGeneration( ) 

Status: CMM::getBusGeneration(uint32 *bus__en_ 
number) 

This command gets the current local bus generation number 
from the network. 55 
The parameter bus_en_number is the current bus genera- 
tion number. 

4) CMM::getSpeedMap( ) 

Status: CMM::getspeedMap(uint32 bus_en_number 
u_char *spd_map) 60 

This command gets the speed map 515 which is associ- 
ated with the bus generation number specified. The param- 
eter bus_en__number is the current bus generation number, 
spd_ map is a pointer to the speed map 515 

5) CMM::getTopologyMap( ) 65 
Status: CMM::getTopologyMap(uint32 bus_en_jmmber, 
uint32 * top_map) 
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This command gets the topology map 520 that is associated 
with the bus generation number specified. The parameter 
bus_en„number is the current bus generation number and 
top_map is a pointer to an array of integer numbers, each 
representing a selLID packet from a 1394 node. 

6) CMM::allocatechannel( ) 

Status: CMM:: allocateChannel(uint32 chan__no) 
This command allocates a channel specified by chan_no. If 
chan_no is all ones (Ox FFFFffff), any channel available 
will be allocated and returned. The parameter charuo is a 
channel number to be allocated. 

7) CMM::deallocatechannel( ) 

Status: CMM::deallocateChannel(uint32 chan_no) 
This command deallocates a channel specified by chan_no. 
The parameter chan_no is the channel number to be deal- 
located. 

8) CMM::allocateBandwidth( ) 

Status: CMM:: allocateBandwidth(uint32 bandwidth) 
This command allocates the bandwidth specified by band- 
width. The parameter bandwidth is the bandwidth to be 
allocated. 

9) CMM::deallocateBandwidth( ) 

Status: CMM::deallocateBandwidth(uint32 bandwidth) 
This command deallocates the bandwidth specified by band- 
width. The parameter bandwidth is the bandwidth to be 
deallocated. 

10) CMM::asyncWrite( ) 

Status: CMM::asyncWrite(GUID guid, u_int64 remote_ 
offset, u_char *data, uint32 data size, uint32 pk_fonnat) 
This command sends an asynchronous write request to the 
remote device, which is identified by guid. The parameter 
guid is the target device's GUID, remote__oflset is the target 
device's memory offset, data is a pointer to data to be sent, 
data_size is the size of data (in byte) to be sent and 
pk_format is the format to use, either quadlet or block for 
data transfer. 

11) CMM::asyncRead( ) 

Status: CMM::asyncRead(GUID guid, ujrt64 remote_ 
offset, u_char *data, uint32 data_size, uint32pk„format) 
This command sends a asynchronous read request to the 
remote device, and returns the data read back. The parameter 
guid is the target device's GUID, remote__oflset is the target 
device's memory offset, data is the pointer to data to be 
received, data_size is the size of data (in byte) to readback 
from remote site, and pk_format is the format to use, either 
quadlet or block for data transfer. 

12) CMM::asyncLock( ) 

Status: CMM::asynclock(GUID guid, u_int64 remote_ 
offset, u_char *old_data u__char *new data, uint32 data_ 
size uint32 exLcode) 

This command makes a lock operation on the specified 
address in the remote device. The parameter old_data is 
used for compare and swap operation. ITie parameter guid is 
the target device's GUID, remote_offset is the target 
device's memory offset, old_data is the pointer to old data, 
new_data is the pointer to the new data, data_size is the 
size of data (in byte) to be sent, and ext_code is the 
extended code to be used for the lock operation 

13) CMM::isoOpen() 

Status: CMM::isoOpen(uint32 direction, uint32 bus_speed, 
uint32 bandwidth, uint32 * port-no) 
This command opens an isochronous port for either sending 
or receiving operation. The actual port opened is returned in 
port_no. The parameter direction is the sending or receiving 
operation, bus_speed is the requested bus speed, bandwidth 
is the maximum bandwidth to be used, and porLno is the 
port number successfully opened. 
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14) CMM::isoClose( ) have bus-specific knowledge. The topology map 520 can be 
Status: CMM: :isoClose(uint32 port_no) generated automatically for those control protocols which 
This command closes the port specificed. The parameter support it, or can be generated with user interaction and 
port_jio is the port number to be closed Close the port stored for later use for those protocols that do not support 
specified. 5 automatic generation. Because topologies can be quite 

15) CMM::isoAttach( ) diverse, the CMM 250 provides a topology iterator function 
Status: CMM::iosAttach(uint32 porLno, u_char *buffer) similar to that of the Service Registry 216. This function 
This command attaches a user buffer to the specified port. allows clients to visit each node in a connection-specific 
The parameter porLno is the port number to be used and manner, with a simple API to move forward or backward 
buffer is the data buffer. io through the net. The client can determine simply that this 

16) CMM::isoDetach( ) device is connected to that one, which is connected to that 
Status: CMM::iosDetach(uint32 port__no, u_char * buffer) one, etc. For clients who simply need to know about all 
This command detaches a user buffer from the specificed devices in a topology, with no concern for connection 
port. The parameter port_no is the port number to be used patterns, the GUID list is provided. Other API's allow the 
and buffer is the data buffer. 15 query to determine if a given modulelD (the identification of 

1 7) CMM: : isoControl( ) a D CM which represents a physical device) is represented in 
Status: CMM::isoControl(uint32 chan, uint32 trigger) the topology, etc. 

This command controls the actual data transfer. It starts The CMM 250 also provides logical connection informa- 

immediately or on some synchronization bit. The parameter tion. This is a connection model that specifies data flow 

chan is the channel to be used for the transfer and trigger is 20 sources and sinks. The API allows inquiries such as "given 

the method to use to start the traffic. DCM module ID X, tell caller all of the DCMs that are 

In addition to the basic four abstractions discussed above listening to it." Other variations on this inquiry model 

(Node, Channel, Bridge and Bandwidth), the following include the ability to ask for all currently active streams of 

concepts describe the bus model. The topology map 520 is a particular data type (e.g. MPEG, SD), etc. 

a connected graph which mirrors the physical connections 25 ft* ha 

between nodes on the network For IEEE 1394, the map is EVENT MANAGER 214 

generated automatically. For other protocols, manual assis- ^ Eyenl Manager 214 of FIG. 4 is designed to support 

tance from the user may be required. The overall system a one-to-many model of communication. It is built above the 

topology is an amalgamation of individual bus topologies. basic messagm g sys tem 212. Objects register interest in 

The generation number provides a way to measure whether 30 events wn ich are then delivered to their event call back entry, 

a pending operation is "stale." Since transactions between Fof ^5^^ objects interested in device status information 

devices depend on being able to access those devices, it is reg ister special call back handlers for this information with 

possible that a pending transaction has not yet completed lhe £vent Manager 214. Objects can attach event filters to 

and one or more of the devices involved have gone away. me ca nback entries that allow them to filter out events that 

When this happens, any modules that care about the bus 35 are QOl curr ently interested in. For example an object 

generation react accordingly. may register for all events from display devices, but filter out 

The generation value is based on the ability to determine mose ^pi^y devices it is not currently using, 

that the bus configuration has changed. For protocols such as Evenlg are broadcasted 5 the messagm g syste m 212 and 

IEEE 1394 the generation is critical because of hot plugging 1q ^ s ^ ^ re ^ stered ^ intcfest in ^ 

support. For others, if hot plugging support can be 40 ^ Tq fc xc ^ T ^ interest ^ 

simulated, then the generation number can be managed as ^ M m m m m tem 

well. If no hot plugging support can be created, then the delivers events to all Event Managers 214 which are 

generation number will always default to 1, meaning that ^ fe ible for ensurin that re gistered objects are 

the bus has not changed since the host system was mitial- MounGd about events . Fnters can be att ached to Event 

ized. A bus can allow a certain maximum ^ number of nodes 45 M rs 2U iQ ^ objects t0 filter out me events as they 

(devices) to be connected and mdividually ada^es Sab le at ivcs an objcct me flcxibility to registcr i^est 

any given time. At any given time, the CMM 250 is ^ an ^ b ^ oyer hflw each eveQt fe used 

informed of how many devices are currently attached and ^ fc a ^ ^ ^ ^ {q specify ^ event x ^ 

addressable (number of nodes) d of intefest tf k QCCUrs ^ evem y ^ £vent Man 

As described more folly below, tlie CMM 250 provides 50 fiUcre and ides an ^ mat ^ applica _ 

bus reset or change notification for buses that support ti ons and DC Ms to build sophisticated event filtering chains, 
dynamic connection. After a bus reset is detected, this 

module assigns new "opaque" ID values to all devices that STREAM MANAGER 335 
have just appeared, determines what devices have gone 

away, invokes the DCM Manager 270 module to create new 55 The Stream Manager 335 of FIG. 4 provides an API for 
DCMs, and posts a bus_change notification event to the configuring end-to-end isochronous ("streaming") connec- 
Event Manager 214, which notifies all registered clients tions. Connections may be point-to -point or utilize unbound 
about the reset. In accordance with the present invention, it sources or sinks. The responsibilities of the Stream Manager 
also provides enough information for the clients to deter- 335 include: configuration of connections; requesting allo- 
mine what devices have disappeared and about any newly 60 cation of network resources; mamtenance of global connec- 
discovered devices. The CMM 250 works with the Event tion information; and support of high-level stream opera- 
Manager 214 to detect and announce dynamic bus changes tions such as plug type checking, splicing and bridging, 
that do not trigger system-wide interrupts or events, thus A Stream Manager 335 runs on each FAV node. The 
bringing some of the advantages of 1394 technology to other interface is based on the IEEE 1212 unit directory model and 
bus protocols. 65 the IEC 6 1883-FDIS plug model (HAV1 refers to units and 
The CMM 250 provides clients with the physical topol- subunits as devices and functional components 
ogy map 520, in a manner that does not require clients to respectively). Point-to-point connections and broadcast con- 
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elections are supported. In IEEE 1394, a broadcast connec- and a connection from the channel to the input plug); it adds 
tion is one in which either the source or sink is not specified an output plug and an input plug to the stream (assuming 
when the connection is requested. Streams do not cross neither are already members). StartBroadcast creates a 
transport boundaries, but bridge devices can be used to feed "broadcastout" connection (e.g., a connection from an out- 
one stream into another. Streams originate and terminate at 5 P ut P lu g to tne channel); it adds an output plug to the stream 
functional components (rather than devices). For IEEE 1394 (assuming it is not already a member). Tap creates a 
networks, the Stream Manager 335 is responsible for alio- "broadcast-in" connection (e g., a connection from the chan- 
cating PCRs (plug control registers) and requesting bus ? el to ™ in P ut P lu s)> 11 * dds ^ "Jf* to the stream 
bandwidth. A standard naming scheme is used for stream ™S it is not already a member). Disconnect Stop- 
j * ■ • r *fn.* Broadcast and Untap drop the connections created by 
ypes, transport types and transmission formats. The stream 10 ^ SlartBroad J st , J Tap respectively. They remove 
type and transport type naming schemes are specified by j (if nQ{ ^ b Qther con ^ QS ^ tne r stream) . 

^ ^T 55100 f T at l arC u w V Streams allow the overlaying of connections as described 

m IEC 1883 Common Isochronous Packets, m IECM 883, e.g., a plug may have many connections (both 

A stream type identifies a media representation, this can point-to-point and broadcast) to the channel used by the 

be a data format (for digital media) or signal format (for 15 streanii Following the connection semantics of IEC-1883, 

analog media), e.g. CD audio, NTSC. A transport type the Stream Manager 335 decides when to remove a plug 

identifies a transport system, two examples are IEC 1883 from a stream by examining the plug's point-to-point con- 

(for connections running over 1394) and "internaf" (for nection counter and a broadcast flag (which indicates 

connections internal to a device). A transmission format whether or not the plug participates in a broadcast 

identifies the data transmission protocol used to send a 20 connection). A plug is removed from a stream when the 

stream type over a transport type. For IEC 1883, the trans- point-to-point connection is 0 and the broadcast flag is false, 

mission format corresponds to the FMT and FDF fields in The underlying network resources used for a stream are 

the Common Isochronous Packet (CIP) header. allocated when the first plug is added to the stream and 

- , . _ __ __ r . . , released when the last plug is removed. In the case of a 

A stream as used by the Stream Manager 335 is based on chanoel to several output phlgSj the manner m 

the isochronous data flow model from IEC 1883 with three which {ht resulting data flow & delivered is transport type 

differences. The first difference is that streams do not restrict dependent and the Stream Manager 335 does not guarantee 

the number of sources and so can have multiple sources mat al] input plugs ^ receive data in the same order, 

provided the transport supports this form of connectivity, for The Stream Manager 335 ma i Qta ins a map of all stream 

example, a UDP "event" stream being fed by many pro- ^ connec tions within the home network. This map includes 

cesses. The second difference is that an IEEE 1394 data flow conncctions ( thosc withm devices) and external 

starts at a device output plug and ends at a device input plug, conne ctions (those over transport systems). The Stream 

while a stream typically starts at a functional component Manager 335 bui i ds the Global Connection Map upon 

output plug, goes to a device output plug, then a device input initialization, after bus reset, and periodically while running 

plug, and ends at a functional component input plug. The ^ case new connections have been added or removed by 

final difference is that streams are typed, e.g., for each noa _HAVl applications). 

stream there is an associated stream type identifying the data Afl AV network can take on maQy topological 
The following summarizes the properties of streams: 1) a configurations, depending on how the user has made the 
stream is associated with a globally unique stream identifier; connections between devices. For example, an IEEE 1394 
2) a stream is carried over a single channel; 3) output 4Q bus allows any topology except a loop. The Stream manager 
functional component plugs ("plugs") and input plugs can 335 of FIG 3 works ^th tne CMM 2 50 to provide services 
join a stream (this can also be stated as "connect to the to ^th routing data from source to destination. This 
channel"); 4) a channel can be connected to zero or more can include many nodes in between. In the event that the 
output plugs and zero or more input plugs; 5) an input plug sourcc ^ destination involve different data types, or are 
can join at most one stream; 6) an output plug can join many 45 se parated by a "data type barrier," it will work with a data 
streams (for example a functional component output plug format manager and Service Registry 216 to handle auto- 
attached to several device output plugs); 7) a stream can be mat i c or requested data translation services as well. Some 
created with no output plug, but no data will flow over the routing can be performed automatically, based on the capa- 
stream until an output plug has joined; and 8) the upper limit bilities provided by the underlying bus architecture. For 
on the number of plugs that can be connected to a channel 5Q examp le, the topology of the IEEE 1394 bus can be precisely 
is transport type dependent. determined, and therefore automatic routing between 
A stream can be viewed as a set of plugs. The following directly-connected 1394 devices can be achieved. However, 
rules apply to connections within a device. Functional other connection mechanisms can require interaction with 
component input plugs can have only one connection (from the user, either to assist the user with making well-known 
a functional component output plug or a device input plug). 55 connections or to have the user indicate to the controlling 
Functional component output plugs can have many connec- software how devices are connected, 
tions (to functional component input plugs and/or device One of the most significant attributes of the IEEE 1394 
output plugs). Device output plugs can have only one technology is isochronous data flow. Additional services 
connection from a functional component output plug. provided by the Stream manager 335 for this kind of data 
Device input plugs can have many connections to functional 6Q include buffer allocation and management. Buffer manage- 
component input plugs. ment includes the provision of a consistent notification 
There are three procedures for adding or removing plugs mechanism to let the client know when data is available, so 
from this set: 1) point-to-point procedure (Connect, that it can be processed. While isochronous data is flowing 
Disconnect); 2) broadcast-out procedure (StartBroadcast, into a client, various memory buffers will be filled with that 
StopBroadcast); and 3) broadcast-in procedure (Tap, Untap). 65 data. As each buffer is filled, the client may want to know so 
Connect creates a point-to-point connection between two that it can handle the data acquisition process from that point 
plugs (e.g., a connection from an output plug to the channel forward. 
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In addition, buffer management can be simplified for 
clients by having the appropriate service modules partition 
memory in a manner that is optimized for the data being 
captured. For example, the client can allocate one large 
space of memory, then specify that it will be used for 5 
capturing a stream of video data. It is possible that the 
optimum configuration of this memory is to separate it into 
scan line- or frame-sized segments, so the client can receive 
one complete line or frame of video on each notification. 
Raw audio and MIDI data will likely have different optimum 10 
segment sizes. Such services require close cooperation 
between the Route and Data Format Managers, and various 
service modules. 

Refer to FIG. 7A and FIG. 7B where an example process 
400 is shown for setting up a data flow. A client wants to 15 
establish a connection between two devices, so at step 410 
it calls to establish an external connection of one of the two 
DCMs that represent those devices. It passes the modulelD 
of the other device's DCM as a parameter. At step 415, the 
DCM that was called then calls the Stream Manager (SM) 20 
335 to assist with making the connection. It passes both the 
source and destination DCM module IDs as parameters. At 
step 420, the SM 335 analyzes the source and destination 
IDs, finds that they are in different nodes (this step may be 
carried out by some other entity before invoking the DFM). 25 
At step 425, the SM 335 asks the CMM 250 of the source 
node for the topology map 520 for its network. At step 430, 
the SM 335 analyzes the topology map 520 to find the 
destination node. 

At step 435 of FIG. 7 A, if the destination node is on the 30 
topology map 520, then no transport protocol translation is 
necessary and step 445 is entered directly. If the destination 
node is not on the map, then at step 475 (FIG. 7B) the SM 
335 asks the Registry 216 for the module with the 
destinationID, to look at the "transmission_protocor' 
attribute, or alternatively, it gets the bus manager ID for that 
module/node. At step 480, the SM 335 then finds a trans- 
mission protocol service module, and sets up the conversion 
process (see separate example for these details). At step 485, 
the above process is repeated if multiple transports need to 40 
be bridged. 

At step 445 of FIG. 7 A, the SM 335 analyzes the 
connection paths to find the best route. If no deterministi- 
cally optimal path can be determined, then a best guess is 45 
accepted. This is done for the entire path from source to 
destination, including intermediate or cross-network bound- 
aries. All necessary connections are made (in the case of 
dynamic buses such as 1394). At step 450, the SM 335 
analyzes the input data formats for source and destination. 5Q 
At step 455, if the formats are the same, then no format 
conversion is necessary. At this point (465) the data flow 
route 400 is complete. 

If conversion is necessary, then at step 460, the SM 335 
asks the Registry 216 for the appropriate format converter 55 
based on input and output format and sets up the conversion 
process. Note that several converters can be chained together 
to achieve the final result from original source to desired 
destination formats. The data flow route 400 is then com- 
plete. 60 

SERVICE REGISTRY 216 

The Service Registry 216 of FIG. 4 provides a mechanism 
to locate devices and services that are available in the HAV 
network. Since all devices and services are represented by 65 
objects, the Service Registry 216 allows any object to 
advertise itself. Typically, resident on an FAV, the Service 
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Registry 16 contains information on local service objects, 
remote service objects and local and remote devices. The 
Service Registry 216 operates by providing an API that 
allows objects to register their unique identifier, a name, and 
a set of attributes that define their characteristics including 
connection point information. Any object wishing to locate 
a particular service or device object can do so by querying 
the Service Registry 216 for the appropriate DCM. 

Attributes associated with an object may be static or 
dynamic, and can be subsequently changed if desired. 
Attribute querying is carried out by specifying a set of 
required attributes which then returns a list of objects that 
match the required attributes. Identifiers returned as a result 
of a query are not guaranteed to be valid. This can happen 
in one of two ways. First, if a device has posted its 
availability into the registry and then has gone off-line. If the 
query arrives between the time of going off-line and actually 
withdrawing the service from the registry, then the identifier 
will be stale. Second, if a query returns a set of identifiers, 
the results may be held within an object for an extended 
period of time. When they are finally used, it may be that the 
service has been withdrawn from the registry. 

The Service Registry 216 is a distributed service. Any 
object that registers with its local Service Registry will be 
accessible via any other instances of the Service Registry 
216 in the HAV network. Each Service Registry 216 works 
with others to ensure that entries are replicated or available 
when required. However, for both performance and resource 
reasons, it is often the case that an item registered in one 
registry will not be visible in another, although the system 
will try to ensure this. This implies that a simple query to a 
local Service Registry 216 may return the local registry's 
view of the global state. It will always be possible to cause 
a remote query to be carried out on behalf of the query to 
ensure that the global state of the system is queried explic- 
itly. 

Queries to the Service Registry 216 return object identi- 
fiers usable as end point for message communication. These 
identifiers may refer to DCMs, services, or any other entity 
in the system accessible via the messaging system. The 
format of the queries allows both sophisticated queries that 
iterate over the global registry or simple queries that are 
confined to a local registry. 

MESSAGING 212 

The messaging system 212 of FIG. 3 is designed to 
provide a reliable high level messaging service that supports 
the transport of 4 different types of messages. (1) Com- 
mands: these flow between objects in the system and are 
used to access functionality. When the target object is a 
device then these messages are sent by a DCM and contain 
actual device control messages. (2) Events: events are used 
as a general purpose asynchronous communication mecha- 
nism that allows both devices and service modules to 
communicate information. Although the messaging system 
212 is used to carry these events they are under the control 
of the Event Manager 214 which uses a broadcast feature of 
the communications infrastructure to send events to those 
who are interested. (3) Errors: errors are similar to events 
except errors are delivered to the source of the command that 
caused the error and then broadcast. (4) Status: these mes- 
sages are designed to be used in response to a query. 

The message system 212 provides both a synchronous and 
an asynchronous send allowing services to operate in either 
mode. The messaging system 212 defines a minimum capa- 
bility to allow interoperability at the message level. This 
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includes the format of identifiers, the format of message 
identifiers and the format of messages. 

The following illustrates an exemplary implementation. 
Local identifiers are 56 bit and are guaranteed to be unique 
to a particular host. Network identifiers are 128 bits and 
consists of a 64 bit node identifier, an 8 bit node type and the 
56 bit local identifier. The generic format for remote mes- 
sages is a 4 octet type field followed by a parameter block. 
This is referred to as the message payload. The mechanism 
to support local messaging is implementation dependent and 
what is required is that local identifiers guarantee consistent 
delivery of the message payload. Remote messaging takes a 
message payload and encapsulates it in a network message. 
The network message format is header plus message pay- 
load. The network message header is 96 bits and consists of 
a reserved 6 bit field, a 2 bit packet type, a 56 bit local 
identifier and a 32 bit message identifier. Depending on the 
actual transport mechanism, this remote message packet will 
be encapsulated in a transport specific message, e.g. IP or 
IEEE 1394. 

INITIALIZATION MANAGER 210 

The Initialization Manager 210 of FIG. 3 is used to bring 
an IAV or FAV node up to initial status. In the case of an IAV 
node this manager 210 will initialize the messaging 212, 
event 214 and registry 216 service. For the FAV node it will 
also invoke initialization routines for the DCM manager 270 
and any pre-loaded services. 

APPLICATION INTERFACE 220 

The Application Interface 220 of FIG. 4 is a proxy to the 
messaging system 212 and provides a means for applications 
to access services and devices in the AV architecture. The 
Application Interface 220 is not necessarily a component of 
the AV architecture, but rather a means of allowing an 
arbitrary application to work with the AV architecture. The 
mechanism used to provide the application object depends 
on the location of the application and the execution envi- 
ronment it uses. Applications can be downloaded from 
external services provided and made resident (e.g., 
instantiated) within an intelligent device (FAV) of a HAVI 
network. An Application so downloaded can query the 
Service Registry 216 to determine connection points for 
controlling devices of the HAVI network. 

There are 3 general cases. The first case is local applica- 
tion running native on the FAV node. These types of 
applications are designed to make use of the native OS and 
hardware features of the FAV node. They are created exter- 
nally to the AV architecture and use the application interface 
to gain access to the AV architecture services. The exact 
means to achieve this are system dependent, but a library 
linked into the application is a typical approach. 

The second case is local application running above the 
FAV interoperability language run-time. In this case, the AV 
architecture uses an architecture neutral run time to support 
level 2 interoperability. This run time can also be used to 
support arbitrary applications written to be hosted on the run 
time. Such applications are managed by the AV architecture 
and will typically access the AV services via a run time 
supplied calling mechanisms. 

The third case is remote application. These applications 
may be running on other devices in the home network such 
as home personal computers (PCs). These applications need 
access to the AV architecture and do so by using the basic 
message passing model of the system. This implies that 
these applications need a partial implementation of the 
messaging infrastructure resident on their host node. 
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GRAPHICS MANAGER 218 

The Graphics Manager 218 of FIG. 3 provides a high 
level API for the management of the user interface (UI) 
associated with devices. The role of the Graphics Manager 
5 218 is to support the User Interface model by providing a 
graphics API that is semantically rich. Low level graphics 
APIs are generally located close to graphic displays and are 
used by the high level graphics API to provide and support 
the UI. 

10 

DEVICE IDENTIFICATION PROCESSES OF 
THE PRESENT INVENTION 

FIG. 8 illustrates a portion 305b of the HAVI communi- 
cation architecture and illustrates an application layer 220, a 

15 device control module 230 for a particular device 20, the 
CMM 250, the link driver layer 320, an electronic device 20 
coupled to the IEEE 1394 communication bus 30 and the 
speed map 515 and topology map 520 data structures. The 
location of the CMM 250 and the link driver layer 320 in the 

20 overall architecture of HAVI is shown in interface 305a of 
FIG. 4. 

As described above, the present invention allows high 
level software programs (e.g., the application layer 220) to 

25 reference devices using a persistent identification scheme. 
Namely, multi-bit persistent Global Unique Identifier num- 
bers (GUIDs) arc assigned to each device and contain a 
vendor portion and a chip series portion. In one 
embodiment, a 64-bit number is used as the GUID. FIG. 8 

3Q illustrates an exemplary communication path whereby the 
application layer 220 issues a command to cause device 20 
to perform some predefined action (e.g., to start "playing" 
some media). The initial command from the application 
layer 220 includes an abstract identifier (e.g., "VCR1") of 
the DCM 230 object and also the action to be done (e.g., 
"play"). 

The DCM 230 of FIG. 8 converts the abstract object name 
into a GUID that matches device 20 and issues another 
command including the GUID and the action, "play," to the 

40 CMM 250. The CMM 250 contains a GUID list 510 in 
accordance with the present invention. The GUID list 510 is 
a listing of GUIDs in order of their associated physical 
identifications (for each respective device). Therefore, the 
GUID list 510 of the present invention functions as an 

45 efficient physical identification to GUID translator and a 
GUID to physical identification translator. The GUID list 
510 is updated by the link driver 320 each time a bus reset 
event is detected. 

The CMM 250, using the GUID list 510, converts the 

50 GUID received from the DCM 230 into the corresponding 
physical identifier for device 20. The CMM 250 then passes 
a message to the link driver layer 320 including the action 
command, "play," and the physical identifier corresponding 
to device 20. The link driver layer 320 interfaces with the 

55 local bus 30 using the physical identifier thereby commu- 
nicating the action command, "play/* to the device 20. The 
speed map 515 and topology map 520 are present for other 
aspects of the present invention described further below. 
FIG. 9A, FIG. 9B and FIG. 9C illustrate exemplary speed 

60 map 515 and topology map 520 data structures. The entries 
of the speed map 515 and topology map 520 data structures 
are organized (e.g., ordered or indexed) based on the physi- 
cal identifier of the devices. The mechanisms for generating 
the speed map 515 and the topology map 520 data structures 

65 are well known within the IEEE 1394 standard. 

FIG. 9A illustrates an exemplary topology map 520 data 
structure used by the present invention. This data structure 
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520 includes a respective entry (of entries $22a-522n) for 
each of the n devices coupled to the local bus 30, The first 
field 524 of each entry corresponds to the device's physical 
identifier as assigned by the local bus layer 330. As shown 
in FIG. 9A, the entries 522a-S22n are ordered according to 5 

their physical identifier, e.g., physical IDO, 

physical_IDl, . . . , physicaUDn. The following fields 526, 
528, 530 for each entry specify port information for each 
physical port of the device. The port information indicates 
the physical connection of that port to another port. Using 
this port information, one can determine the manner in 
which the n devices of the local bus 30 are physically 
coupled together in the HAVI network. Topology map 520 
data structures of the format shown in FIG. 9A are well 
known in the art and are re-generated upon each local bus 
reset. 

FIG. 9B illustrates an exemplary one-dimensional speed 
map data structure 515a used by the present invention. This 
data structure 515a includes a respective entry (of entries 
531a-531w) for each of the n devices coupled to the local 2Q 
bus 30. The first field 532 of each entry corresponds to the 
device's physical identifier as assigned by the local bus layer 
330. As shown in FIG. 9B, the entries 531a-531* are 
ordered according to their physical identifier, e.g., physical_ 
IDO, physicaLJDl, . . , , physicaLJDn. Field 534 indicates %$ 
information pertinent to the communication protocol 
(including communicate rate) available for the device. 
Speed map 515fl data structures of the format shown in HG. 
9B are well known in the art and are re-generated upon each 
local bus reset. 30 

FIG. 9C illustrates a two dimensional speed map 5156 
data structure used by the present invention. Speed map 
515b is a matrix where each matrix entry 546 conveys 
information regarding the communication speed between 
referenced devices (e.g., devices referenced by phy_id n 35 
and phy_jd 2). The speed map 5155 has a first index 542 
and a second index 544, both being ordered according to 
their physical identifiers. Speed map 515/) data structures of 
the format shown in FIG. 9C are well known in the art and 
are re-generated upon each local bus reset. 40 

FIG. 10A illustrates an exemplary HAVI network 560a 
having five devices coupled to the local bus. Device 562 has 
a physical identifier (0) and a GUID(Y); device 564 has a 
physical identifier (1) and a GUID(Z); device 566 has a 
physical identifier (2) and a GUID(I); device 568 has a 45 
physical identifier (3) and a GUID(J) and device 570 has a 
physical identifier (4) and a GUID(X). Each of the GUID 
values is unique and persistent. The physical identifier 
values for the devices of FIG. 10A can become reassigned 
after a local bus reset. 50 

FIG. 11A illustrates the resulting GUID list 510a com- 
piled by the present invention based on the exemplary HAVI 
network 560a of FIG. 10A. The GUID list 510a contains 
five entries, one for each device of the HAVI network. As 
shown, the GUID values in the GUID list 510a are ordered, 55 
e.g., GUID(Y); GUID(Z); GUID(I); GUID(J); and GUID 
(X), according to the corresponding physical identification 
values, 0, 1, 2, 3 and 4, respectively. In one embodiment, 
GUID list 510a is compiled by the link driver 320 and stored 
in computer readable memory. 60 

FIG. 10B illustrates another exemplary HAVI network 
560b having six devices coupled to the local bus. Network 
560b is similar to network 560a except device 566 is 
removed and devices 572 and 574 are added. In network 
5606, device 572 has a physical identifier (1) and a GUID 65 
(U) and device 574 has a physical identifier (5) and a 
GUID(N). Some of the physical identifier values between 



FIG. 10A and FIG. 10B have been reassigned due to a local 
bus reset. The reassigned physical identifiers for the remain- 
ing devices are as follows: device 562 has physical identifier 
(0), device 564 has physical identifier (3), device 568 has 
physical identifier (4) and device 570 has physical identifier 
(2). Each of the GUID values is unique and persistent for all 
devices, 

FIG. 11B illustrates the resulting GUID list 5106 com- 
piled by the present invention based on the exemplary HAVI 
network 560b of FIG. 10B. The GUID list 510b contains six 
entries, one for each device of the HAVI network 560b. As 
shown, the GUID values in the GUID list 510b are ordered, 
e.g., GUID(Y); GUID(U); GUID(X); GUID(Z); GUID(J) 
and GUID(N), according to the corresponding physical 
identification values, 0, 1, 2, 3, 4 and 5, respectively. In one 
embodiment, the GUID list 510b is compiled by the link 
driver 320 and stored in computer readable memory. 

FIG. 12Aillustrates a GUID status table 630 generated by 
the CMM 250 of the present invention each time a local bus 
reset is generated. The GUID status table 630 includes 
entries 632a-632# regarding (1) which devices remain con- 
nected to the local bus 30 since the last GUID list 510 was 
compiled, e.g., after a local bus reset, (2) which devices have 
been just removed and (3) which devices have been just 
added since the last GUID list 510 was compiled. A first field 
632 represents the GUID value of the device and an asso- 
ciated field 634 represents the current status of that device. 
FIG. 12A represents an exemplary table 630 generated by 
CMM 250 as a result of the exemplary configurations of 
FIG. 10A and FIG. 10B. As shown in table 630, the devices 
having GUID(Y), GUID(X), GUID(Z), and GUID(J) remain 
after the local bus reset. However, the devices having 
GUID(U), and GUID(N) have been added after the local bus 
reset and the device having GUID(I) was removed after the 
local bus reset. In one embodiment, the GUID table 630 is 
compiled by the CMM 250 and stored in computer readable 
memory. 

FIG. 12B illustrates a subset status table 650 generated by 
the CMM 250 which contains entries 652a-652b indicating 
only which devices have been added to the local bus 30 since 
the last GUID list 510 was compiled. Likewise, FIG. 12C 
illustrates a subset status table 660 generated by the CMM 
250 which contains entries (662a) indicating only which 
devices have been removed from the local bus 30 since the 
last GUID list 510 was compiled. In one embodiment, the 
GUID tables 650-660 are compiled by the CMM 250 and 
stored in computer readable memory. Device status tables 
630, 650 and 660 are forwarded to objects within the HAVI 
architecture that establish callback handlers within the 
CMM 250 to receive this information. 

FIG. 13 illustrates a flow diagram 700 of the steps 
performed by the link driver 320 of the present invention for 
compiling a current GUID table 510 in response to a local 
bus reset. After a local bus reset, physical identifiers of 
devices are reassigned by the local bus 30. At step 710, if a 
local bus reset is reported to the link driver 320, then step 
715 is entered. At step 715, current GUID list is erased and 
the link driver 320 determines the number of devices, n, that 
are currently coupled to the local bus 30. A number of well 
known mechanisms can be used to implement step 715. At 
step 720, a counter is set to zero. At step 725, the link layer 
320 issues a request to the device coupled to the local bus 30 
and having the physical identifier corresponding to the 
counter value. The request is for the GUID value of this 
device. At this point, the link layer 320 is unaware which 
device this is. 

At step 730, the link layer 320 receives the return GUID 
value from the device with the physical identifier of the 
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counter value and places this GUID value into a next entry 
of the current GUID list 510 (the entry position also corre- 
sponds to the counter value). At step 735, the counter is 
incremented by one. At step 740, a check is made if the 
counter is equal to n (the maximum number of devices on 
the local bus). If not, then step 725 is entered again to 
continue compiling the current GUID list. If so, then at step 
745, the link layer 320 forwards the CMM 250 a copy of the 
current GUID list 510. It is appreciated that physical iden- 
tifiers are assigned by the local bus 30 from 0 to (n-1) 
values. After process 700, a current GUID list 510 like those 
shown in FIG. 11A and FIG. 11B is compiled. 

FIG. 14 illustrates a flow diagram 800 of the steps 
performed by the Link layer 320 and the CMM 250 of the 
present invention for compiling the device status tables 630, 
650, 660 in response to a local bus reset. As discussed above, 
process 700 generates a current GUID list 510 in response 
to a local bus reset and passes the current list to the CMM 
250. At step 820, the current GUID list is received and the 
last GUID list received by the CMM 250 is retained and 
marked as a "previous" GUID list. At step 825, the CMM 
250 compares the entries of the previous GUID list and the 
current GUID list 510 and generates GUID table 650 based 
on the new GUID values that are present in the current 
GUID list 510 but not in the previous GUID list. Any object 
within the HAVI architecture that previously established a 
callback handler with the Event Manager 214 for the infor- 
mation of table 650 is sent a message including the status 
information of table 650. 

At step 830, the CMM 250 compares the entries of the 
previous GUID list and the current GUID list 510 and 
generates GUID table 660 based on any GUID values that 
are no longer present in the current GUID list 510 but were 
present in the previous GUID list. Any object within the 
HAVI architecture that previously established a callback 
handler with the Event Manager 214 for the information of 
table 660 is sent a message including the status information 
of table 660. Optionally, at step 830, the information from 
tables 660 and 650 can be combined with the GUID values 
that are common to both the previous and current GUID lists 
thereby generating table 630. At step 835, the CMM 250 
erases the previous GUID list and uses only the current 
GUID list 510. By performing process 800, the CMM 250 
and the link layer 320 of the present invention eliminate the 
burden from higher level application programs of tracking 
which devices are on the local bus while providing the high 
level application programs with device status information. 

FIG. ISA illustrates a flow diagram 850 of steps per- 
formed by the present invention for translating GUID values 
into physical identifications using the GUID list 510 passed 
to the CMM 250. At step 855, an application program issues 
a command to control a device(x) and this command is 
received by the DCM of the device(x). At step 860, the DCM 
issues a command to the CMM 250 including device(x)*s 
GUID value which is known to the DCM. At step 865, the 
CMM 250 determines the index (e.g., entry order) of the 
device(x)'s GUID within the GUID list 510. This value is 
the physical identifier of device(x). At step 870, the CMM 
250 issues a command to the link driver layer 320 including 
device(x)'s physical identifier and an action command. The 
link driver layer 320 then commands device(x) using the 
received physical identifier. Using process 850, high level 
applications do not need to be aware of a device's physical 
identifier but can use the constant GUID value. 

FIG. 15B illustrates a flow diagram 900a of steps per- 
formed by the present invention for accessing speed map 
information with respect to two devices given their GUIDs. 
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At step 910, an application layer issues a command to 
determine the communication speed supported between 
device(x) and device(y). The request includes the GUID 
values for device(x) and device(y). At step 915, the CMM 

5 250 receives this command and the GUID values. The CMM 
250 translates the GUID values into two physical identifiers 
based on the index of the GUIDs within the GUID list 510. 
At step 920, the CMM 250 then accesses (e.g., indexes) a 
two dimensional speed map data structure 5156 with the 

1Q obtained two physical identifiers. The speed map thereby 
returns the proper speed information. At step 925, the CMM 
250 forwards the determined speed information to the 
requesting application layer. 

FIG. 15C illustrates a flow diagram 950a of steps per- 

15 formed by the present invention for accessing topology map 
information with respect to a device given its GUID value. 
At step 955, an application layer issues a command to 
determine the topology of a device(y). The request includes 
the GUID value for device(y). At step 960, the CMM 250 

20 receives this command and the GUID value. The CMM 250 
translates the GUID value into a physical identifier based on 
the index of the GUID within the GUID list 510. At step 965, 
the CMM 250 then accesses (e.g., indexes) a topology data 
structure 520 with the obtained physical identifier. The 

25 topology map thereby returns the proper topology informa- 
tion for device(y). At step 970, the CMM 250 forwards the 
determined topology information to the requesting applica- 
tion layer. 

FIG. 15D illustrates a flow diagram 900!? of steps per- 

30 formed by the present invention for accessing speed map 
information with respect to two devices given their GUIDs. 
The difference between process 9006 and 900a (FIG. 15A) 
is that the application program determines the speed 
information, not the CMM 250. At step 980, an application 

35 layer issues a command to determine the communication 
speed between device(x) and device(y). At step 982, the 
CMM 250 receives this command and forwards the current 
GUID list 510 as well as a copy of the speed map 5156 (or 
pointers to these data structures) to the application program. 

40 At step 984, the application program translates the GUID 
values of the two devices into two physical identifiers based 
on the index of the GUIDs within the GUID list 510. The 
application program then accesses (e.g., indexes) the two 
dimensional speed map data structure 5156 with the 

45 obtained two physical identifiers. The speed map thereby 
returns the proper speed information. 

FIG. 15E illustrates a flow diagram 9506 of steps per- 
formed by the present invention for accessing topology 
information with respect to a device given its GUID. The 

50 difference between process 9506 and 950a (FIG. 15B) is that 
the application program determines the topology 
information, not the CMM 250. At step 990, an application 
layer issues a command to determine the topology informa- 
tion of device(y). At step 992, the CMM 250 receives this 

55 command and forwards the current GUID list 510 as well as 
a copy of the topology map 520 (or a pointer to this data 
structure) to the application program. At step 994, the 
application program translates the GUID value of the device 
(y) into a physical identifier based on the index of the GUID 

60 within the GUID list 510. The application program then 
accesses (e.g., indexes) the topology data structure 520 with 
the obtained physical identifier. The topology map thereby 
returns the proper topology information. 

It is appreciated that by providing the GUID list 510, the 

65 present invention allows high level applications to utilize 
persistent device identifiers (GUIDs) to references devices. 
Upon a bus reset, the high level devices are not burdened 
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with the reassignments of physical identifiers that are done 
at the local bus level. The GUID list 510 is particularly 
efficient by organizing the ordering of GUIDs to conform to 
the physical identifier value. This reduces memory required 
to store the GUID list 510 and creates an efficient index 5 
mechanism. 

The preferred embodiments of the present invention, a 
method and system for providing efficient device identifi- 
cation using a GUID list within a consumer electronics 
based audio /video network, are thus described. While the 10 
present invention has been described in particular 
embodiments, it should be appreciated that the present 
invention should not be construed as limited by such 
embodiments, but rather construed according to the below 
claims. 15 

What is claimed is: 

1. A method of providing device identification to access 
information within a network, said method comprising the 
steps of: 

a) constructing a list of global unique identifiers (GUIDs) 20 
wherein each GUID identifies a unique device of said 
network and wherein said constructing orders GUIDs 
within said list of GUIDs according to their associated 
physical identifier values, wherein said physical iden- 
tifier values are assigned by a local bus of said network; 25 

b) receiving a request originating from an application 
program to determine a communication speed value 
corresponding to a device of said network wherein said 
request includes a first GUID corresponding to said 3Q 
device; 

c) using said fist of GUIDs to determine a first index value 
corresponding to a position of said first GUID within 
said list of GUIDs; and 

d) referencing a speed map data structure with said first 35 
index value to obtain said communication speed value, 
wherein said speed map data structure is organized 
based on physical identifiers. 

2. A method as described in claim 1 further comprising the 
step of e) communicating said communication speed value 40 
to said application program and wherein said network is a 
network of the home audio/visual initiative (HAVT) archi- 
tecture and wherein said local bus is of the IEEE 1394 
standard. 

3. A method as described in claim 1 further comprising the 45 
steps of: 

f) in response to a local bus reset, renumbering physical 
identifiers of devices of said network that are coupled 
to said local bus; 

g) rebuilding said speed map data structure based on 50 
renumbered physical identifiers of step f); and 

h) constructing a new list of GUIDs based on said 
renumbered physical identifiers of step f). 

4. A method as described in claim 1 wherein each GUID 55 
is a persistent multi-bit value comprising a vendor code 
portion and a chip series code portion. 

5. A method as described in claim 1 wherein said step a) 
is performed in response to a local bus reset and comprises 
the steps of: 60 

al) receiving from said local bus an indication of the 
number of devices of said local bus; 

a2) starting with physical identifier zero and incrementing 
to a last physical identifier corresponding to said num- 
ber of devices of said local bus, forwarding requests to 65 
said devices of said local bus individually requesting 
their GUIDs; 
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a3) recording into said list of GUIDs any GUIDs returned 
from said devices of said local bus, said GUIDs 
recorded into positions said list of GUIDs based on 
their corresponding physical identifier values; and 

a4) storing said list of GUIDs into a computer readable 
memory unit. 

6. A method of providing device identification to access 
information within a network, said method comprising the 
steps of: 

a) constructing a list of global unique identifiers (GUIDs) 
wherein each GUID identifies a unique device of said 
network and wherein said constructing orders GUIDs 
within said list of GUIDs according to their associated 
physical identifier values, wherein said physical iden- 
tifier values are assigned by a local bus of said network; 

b) receiving a request originating from an application 
program to determine topology information corre- 
sponding to a device of said network wherein said 
request includes a first GUID corresponding to said 
device; 

c) using said list of GUIDs to determine a first index value 
corresponding to a position of said first GUID within 
said list of GUIDs; and 

d) referencing a topology map data structure with said 
first index value to obtain said topology information, 
wherein said topology map data structure is organized 
based on physical identifiers. 

7. A method as described in claim 6 further comprising the 
step of e) communicating said topology information to said 
application program and wherein said network is a network 
of the home audio/visual initiative (HAVI) architecture and 
wherein said local bus is of the IEEE 1394 standard. 

8. A method as described in claim 6 further comprising the 
steps of: 

f) in response to a local bus reset, renumbering physical 
identifiers of devices of said network that are coupled 
to said local bus; 

g) rebuilding said topology map data structure based on 
renumbered physical identifiers of step f); and 

h) constructing a new list of GUIDs based on said 
renumbered physical identifiers of step f). 

9. A method as described in claim 6 wherein each GUID 
is a persistent multi-bit value comprising a vendor code 
portion and a chip series code portion. 

10. A method as described in claim 6 wherein said step a) 
is performed in response to a local bus reset and comprises 
the steps of: 

al) receiving from said local bus an indication of the 
number of devices of said local bus; 

a2) starting with physical identifier zero and incrementing 
to a last physical identifier corresponding to said num- 
ber of devices of said local bus, forwarding requests to 
said devices of said local bus individually requesting 
their GUIDs; 

a3) recording into said list of GUIDs any GUIDs returned 
from said devices of said local bus, said GUIDs 
recorded into positions said list of GUIDs based on 
their corresponding physical identifier values; and 

a4) storing said list of GUIDs into a computer readable 
memory unit. 

11. A method of providing device identification within a 
network, said method comprising the steps of: 

a) constructing a list of global unique identifiers (GUIDs) 
wherein each GUID is persistent and identifies a unique 
device of said network and wherein said constructing 
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orders GUIDs within said list of GUIDs according to 
their associated physical identifier values, wherein said 
physical identifier values are assigned by a local bus of 
said network; 

b) receiving a request originating from an application 5 
program to communicate with a device of said network 
wherein said request includes an identifier correspond- 
ing to said device; 

c) translating said identifier into a first GUID correspond- 
ing to said device; 10 

d) using said list of GUIDs to determine a first index value 
corresponding to a position of said first GUID within 
said list of GUIDs wherein said first index value is a 
first physical identifier; and 

e) issuing a communication to said device over said local 15 
bus using said first physical identifier, wherein said 
communication corresponds to said application pro- 
gram request. 

12. A method as described in claim 11 wherein said 
network is a network of the home audio/visual initiative 20 
(HAVI) architecture and wherein said local bus is of the 
IEEE 1394 standard, 

13. A method as described in claim 11 further comprising 
the steps of: 

f) in response to a local bus reset, renumbering physical 25 
identifiers of devices of said network that are coupled 

to said local bus; and 

g) constructing a new list of GUIDs based on said 
renumbered physical identifiers of step f). 

14. A method as described in claim 11 wherein each 30 
GUID is a multi-bit value comprising a vendor code portion 
and a chip series code portion. 

15. A method as described in claim 11 wherein said step 

a) is performed in response to a local bus reset and com- ^ 
prises the steps of: 

al) receiving from said local bus an indication of the 

number of devices of said local bus; 
a2) starting with physical identifier zero and incrementing 
to a last physical identifier corresponding to said mim- 4Q 
ber of devices of said local bus, forwarding requests to 
said devices of said local bus individually requesting 
their GUIDs; 

a3) recording into said list of GUIDs any GUIDs returned 
from said devices of said local bus, said GUIDs 45 
recorded into positions said list of GUIDs based on 
their corresponding physical identifier values; and 

a4) storing said list of GUIDs into a computer readable 
memory unit. 

16. An electronic system having a processor, an internal 50 
bus and a computer readable memory unit, said system 
coupled to an IEEE 1394 local bus, wherein said memory 
unit having instructions stored therein that implement a 
method of providing device identification to access infor- 
mation within a network, said method comprising the steps 55 
of: 

a) constructing a list of global unique identifiers (GUIDs) 
wherein each GUID is persistent and identifies a unique 
device of said network and wherein said constructing 
orders GUIDs within said list of GUIDs according to <so 
their associated physical identifier values, wherein said 
physical identifier values are assigned by a local bus of 
said network; 

b) receiving a request originating from an application 
program to determine information corresponding to a 65 
device of said network wherein said request includes a 
first GUID corresponding to said device; 
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c) using said list of GUIDs to determine a first index value 
corresponding to a position of said first GUID within 
said list of GUIDs; and 

d) referencing a map data structure with said first index 
value to obtain said information wherein said map data 
structure is organized based on physical identifiers. 

17. An electronic system as described in claim 16 wherein 
said method further comprises the step of e) communicating 
said information to said application program and wherein 
said network is a network of the home audio/visual initiative 
(HAVI) architecture and wherein said local bus is of the 
IEEE 1394 standard. 

18. An electronic system as described in claim 16 wherein 
said method further comprises the steps of: 

f) in response to a local bus reset, renumbering physical 
identifiers of devices of said network that are coupled 
to said local bus; 

g) rebuilding said map data structure based on renum- 
bered physical identifiers of step f); and 

h) constructing a new list of GUIDs based on said 
renumbered physical identifiers of step f), 

19. An electronic system as described in claim 16 wherein 
each GUID is a multi-bit value comprising a vendor code 
portion and a chip series code portion. 

20. An electronic system as described in claim 16 wherein 
said step a) of said method is performed in response to a 
local bus reset and comprises the steps of: 

al) receiving from said local bus an indication of the 
number of devices of said local bus; 

a2) starting with physical identifier zero and incrementing 
to a last physical identifier corresponding to said num- 
ber of devices of said local bus, forwarding requests to 
said devices of said local bus individually requesting 
their GUIDs; 

a3) recording into said list of GUIDs any GUIDs returned 
from said devices of said local bus, said GUIDs 
recorded into positions said list of GUIDs based on 
their corresponding physical identifier values; and 

a4) storing said list of GUIDs into said computer readable 
memory unit. 

21. An apparatus for providing device identification to 
access information within a network, said apparatus com- 
prising: 

a) means for constructing a list of global unique identifiers 
(GUIDs), wherein each GUID is persistent and identi- 
fies a unique device of said network, by ordering 
GUIDs within said list of GUIDs according to their 
associated physical identifier values, wherein said 
physical identifier values are assigned by a local bus of 
said network; 

b) means for receiving a request originating from an 
application program to determine information corre- 
sponding to a device of said network wherein said 
request includes a first GUID corresponding to said 
device; 

c) means for using said list of GUIDs to determine a first 
index value corresponding to a position of said first 
GUID within said list of GUIDs; and 
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d) means for referencing a map data structure with said 
first index value to obtain said information wherein said 
map data structure is organized based on physical 
identifiers. 

22. An apparatus as described in claim 21 wherein said S 
means for constructing is responsive to a local bus reset and 
comprises: 

al) means for receiving from said local bus an indication 
of the number of devices of said local bus; 

a2) means for starting with physical identifier zero and 1C 
incrementing to a last physical identifier corresponding 
to said number of devices of said local bus, forwarding 
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requests to said devices of said local bus individually 
requesting their GUIDs; 
a3) means for recording into said list of GUIDs any 
GUIDs returned from said devices of said local bus, 
said GUIDs recorded into positions said list of GUIDs 
based on their corresponding physical identifier values; 
and 

a4) means for storing said list of GUIDs into said com- 
puter readable memory unit. 

* * * * * 
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